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Reconnu dans le monde pour sa puissance et son elegance, Symfony est issu de 
plus de dix ans de savoir-faire. Le framework open source de Sensio federe une 
tres forte communaute de developpeurs PHP professionnels. II leur offre des 
outils et un environnement MVC pour creer des applications web robustes, main- 
tenables et evolutives. 

Au fil d'une demarche rigoureuse et d'un exemple concret d'application web 2.0, 
ce cahier decrit le bon usage des outils Symfony mis a la disposition du develop- 
peur : de I'architecture MVC et autres design patterns a I'abstraction de base de 
donnees et au mapping objet-relationnel avec Doctrine, en passant par les tests 
unitaires et fonctionnels, la gestion des URL, des formulaires ou du cache, 
I'internationalisation ou encore la generation des interfaces d'administration... 



@ 



Adapte du tutoriel Jobeet mis a jour en francais 
http://www.symfony-project.org/jobeet/ 



Telechargez le code source ! 



Sommaire 

Une etude de cas Symfony : Jobeet • Bonnes pratiques • Environnements d'execution • 
Configurer le serveur web • Le serveur virtuel • Integrer Subversion • Specifications fonc- 
tionnelles • Etude des besoins • Concevoir le modele • Configurer MySQL • L'ORM Doctrine 

• Schema de la base • Architecture MVC • Le controleur : les actions • La vue : les tem- 
plates • Images et feuilles de style • Helpers • Erreur 404 • Interaction client/serveur • 
Le framework de routage • Configuration des URL • Routage • Emuler HTTP PUT et 
DELETE • Debogage • Optimiser le modele • Deboguer les requetes SQL • Refactoring 
MVC en continu • Partiels • Slots • Composants • Tests unitaires • Le framework Lime 

• Integrite du modele • Maintenabilite du code • Tests fonctionnels • Simuler le naviga- 
teur • Tester I'application • Gestion des formulaires • Valider les donnees • Integration 
dans les templates et actions • Securite • Attaques CSRF et XSS • Maintenance auto- 
matisee • Interface d'administration • Generation automatique • Configuration des vues 

• Ergonomie • Ajout de fonctionnalites • Authentification et droits d'acces • Sessions • 
Politique de droits • Securiser le backend • Flux de syndication Atom et services web • 
XML, JSON et YAML • Envoi d'e-mails • Moteur de recherche • PHP Lucene • Dynamiser 
interface avec Ajax • JavaScript jQuery • Requetes Ajax • Internationalisation et locali- 
sation • Support des langues, jeux de caracteres et encodages • Traduction dynamique 

• Plug-ins Symfony • Gestion du cache • Reduire les temps de chargement • Deploiement 
en production • Connexion SSH et rsync • Le format YAML • Fichiers de configuration 
settings. yml et factories. yml. 



Fabien Potencier est inge- 
nieur civil des Mines de Nancy et 
diplome du mastere Entrepre- 
neurs a HEC. II a cree le frame- 
work Symfony dont il est le deve- 
loppeur principal. Co-fondateur 
de Sensio, il dirige Sensio Labs, 
agence specialisee dans les tech- 
nologies Open Source. 

Diplome d'une licence specialisee 
en developpement informatique, 
Hugo Hamon a rejoint Sensio 
Labs en tant que developpeur 
web. Passionne par PHP, il a 
fonde le site Apprendre-PHP .com 
et promeut le langage en milieu 
professionnel en s'investissant 
dans I'AFUP et dans la commu- 
naute Symfony. 



symfony 



& doctrine 



SENSIOLABS 



u Programmeur 

Symfony 



Collection « Les cahiers du programmeur » 



G. Poncon et J. Pauli. - Zend Framework. N°12392, 2008, 460 pages. 
L. Jayr. Flex 3. Applications Internet riches. N°12409, 2009, 226 pages. 
P. Roques. - UML 2. Modeliser une application web. N°12389, 6 e edition, 2008, 247 pages 
A. Goncalves. - Java EE 5. N°12363, 2 e edition, 2008, 370 pages 
E. Puybaret. - Swing. N°12019, 2007, 500 pages 
E. Puybaret. - Java 1.4 et 5.0. N°11916, 3 e edition, 2006, 400 pages 
J. Moliere. - J2EE. N°11574, 2 e edition, 2005, 220 pages 

R. Fleury- Java/XML. N°11316, 2004, 218 pages 
J. Protzenko, B. Picaud. - XUL. N°11675, 2005, 320 pages 
S. Mariel. - PHP 5. N° 11234, 2004, 290 pages 

CHEZ LE MEME EDITEUR 

C. Porteneuve. - Bien developper pour le Web 2.0. N°12391, 2 e edition 2008, 600 pages. 
E. Daspet, C. Pierre de Geyer. - PHP 5 avance. N°12369, 5 e edition, 2008, 844 pages 
G. Poncon. - Best practices PHP 5. Les meilleures pratiques de developpement en PHP. N°1 1676, 2005, 470 pages 
T. Ziade. - Programmation Python. - N°12483, 2 e edition, 2009, 530 pages 
C. Pierre de Geyer, G. Poncon. - Memento PHP 5 et SQL. N°12457, 2 e edition, 2009, 14 pages 
J.-M. Defrance. - Premieres applications Web 2.0 avec Ajax et PHP. N°12090, 2008, 450 pages 
D. Seguy, P. Gamache. - Securite PHP 5 et MySQL. N°121 14, 2007, 250 pages 
A. Vannieuwenhuyze. Programmation Flex 3. N°12387, 2008, 430 pages 
V. Messager-Rota. - Gestion de projet. Vers les methodes agiles. N°12158, 2 e edition, 2009, 252 pages 
H. Bersini, I. Wellesz. - L'oriente objet. N°12084, 3 e edition, 2007, 600 pages 

P. Roques. - UML 2 par la pratique. N°12322, 6 e edition, 368 pages 
S. Bordage. - Conduite de projet Web. N°12325, 5 e edition, 2008, 394 pages 
J. Dubois, J.-P. Retaille, T. Templier. - Spring par la pratique. Java/J2EE, Spring, Hibernate, Struts, Ajax. - N°11710, 2006, 518 pages 

A. Boucher. - Memento Ergonomie web. N°12386, 2008, 14 pages 
A. Fernandez-Toro. - Management de la securite de I'information. Implementation ISO 27001. N°12218, 2007, 256 pages 

Collection « Acces libre » 
Pour que I'informatique soit un outil, pas un ennemi ! 

Economie du logiciel libre. F. Elie. N°12463, 2009, 195 pages 
Hackez votre Eee PC. L'ultraportable efficace. C. Guelff. N°12437, 2009, 306 pages 
Joomla et Virtuemart - Reussir sa boutique en ligne. V. Isaksen, T. Tardif. - N°12381, 2008, 270 pages 
Open ERP - Pour une gestion d'entreprise efficace et integree. F. Pinckaers, G. Gardiner. - N°12261, 2008, 276 pages 
Reussir son site web avec XHTML et CSS. M. Nebra. - N°12307, 2 e edition, 2008, 316 pages 
Ergonomie web. Pour des sites web efficaces. A. Boucher. - N°12479, 2 e edition, 2009, 456 pages 
Gimp 2 efficace - Dessin et retouche photo. C. Gemy. - N°12152, 2 e edition, 2008, 402 pages 
OpenOffice.org 3 efficace. S. Gautier, G. Bignebat, C. Hardy, M. Pinquier. - N°12408, 2009, 408 pages avec CD-Rom. 
Reussir un site web d'association... avec des outils libres. A.-L. et D. Quatravaux. - N°12000, 2 e edition, 2007, 372 pages 
Reussir un projet de site Web. N. Chu. - N°12400, 5 e edition, 2008, 230 pages 



Fabien Potencier 
Hugo Hamon 



les Cahiers 

du Programmeur 

Symfony 

Mieux developper en PHP 
avec Symfony 1.S et Doctrine 



EYROLLES 

• 



EDITIONS EYROLLES 
61, bd Saint-Germain 
75240 Paris Cedex 05 
www. editions-eyrolles . com 



Remerciements a Franck Bodiot pour certaines illustrations d'ouverture de chapitre. 



Le code de la propriete intellectuelle du l er juillet 1992 interdit en effet expressement la photocopie a usage collectif sans 
autorisation des ayants droit. Or, cette pratique s'est generalisee notamment dans les etablissements d'enseignement, 
provoquant une baisse brutale des achats de livres, au point que la possibility meme pour les auteurs de creer des ceuvres 
nouvelles et de les faire editer correctement est aujourd'hui menacee. 

En application de la loi du 11 mars 1957, il est interdit de reproduire integralement ou partiellement le present ouvrage, 
sur quelque support que ce soit, sans autorisation de l'editeur ou du Centre Francais d'Exploitation du Droit de Copie, 20, 
rue des Grands-Augustins, 75006 Paris. 
© Groupe Eyrolles, 2009, ISBN : 978-2-212-12494-1 



DANGER 



PHOTOCOPILLAGE 
TUELELIVRE 



Avant-propos 



COMMUNAUTE 

Une etude de cas communautaire 

Pour Askeet, il avait ete demande a la commu- 
naute des utilisateurs de Symfony de proposer une 
fonctionnalite a ajouter au site. L'initiative eut du 
succes et le choix se porta sur I'ajout d'un moteur 
de recherche. Le vceu de la communaute fut rea- 
lise, et le chapitre consacre au moteur de 
recherche est d'ailleurs rapidement devenu I'un 
des plus populaires du tutoriel. 
Dans le cas de Jobeet, I'hiver a ete celebre le 
21 decembre avec I'organisation d'un concours de 
design ou chacun pouvait soumettre une charte gra- 
phique pour le site. Apres un vote communautaire, 
la charte de I'agence americaine centre{source} 
fut choisie. C'est cette interface graphique qui sera 
integree tout au long de ce livre. 



Apres plus de trois ans d'existence en tant que projet Open Source, 
Symfony est devenu l'un des frameworks incontournables de la scene 
PHP. Son adoption massive ne s'explique pas seulement par la richesse 
de ses fonctionnalites ; elle est aussi due a 1' excellence de sa documenta- 
tion - probablement l'une des meilleures pour un projet Open Source. 

La sortie de la premiere version officielle de Symfony a ete celebree avec 
la publication en ligne du tutoriel Askeet, qui decrit la realisation d'une 
application sous Symfony en 24 etapes prevues pour durer chacune une 
heure. Publie a Noel 2005, ce tutoriel devint un formidable outil de pro- 
motion du framework. Nombre de developpeurs ont en effet appris a 
utiliser Symfony grace a Askeet, et certaines societes l'utilisent encore 
comme support de formation. 

Le temps passant, et avec l'arrivee de la version 1.2 de Symfony, il fut 
decide de publier un nouveau tutoriel sur le meme format qu Askeet. Le 
tutoriel Jobeet fut ainsi publie jour apres jour sur le blog officiel de Sym- 
fony, du l er au 24 decembre 2008 ; vous lisez actuellement sa version 
editee sous forme de livre papier. 



Decouvrir I'etude de cas develop pee 

Cet ouvrage decrit le developpement d'un site web avec Symfony, depuis 
ses specifications jusqu'a son deploiement en production, en 21 chapitres 
d'une heure environ. Au travers des besoins fonctionnels du site a deve- 
lopper, chaque chapitre sera l'occasion de presenter non seulement les 
fonctionnalites de Symfony mais egalement les bonnes pratiques du 
developpement web. 



L'application developpee dans cet ouvrage aurait pu etre un moteur de 
blog - exemple souvent choisi pour d'autres frameworks ou langages de 
programmation. Nous souhaitions cependant un projet plus riche et plus 
original, afin de demontrer qu'il est possible de developper facilement et 
rapidement des applications web professionnelles avec Symfony. C'est 
au chapitre 2 que vous en decouvrirez les specificites ; pour le moment, 
seul son nom de code est a memoriser : Jobeet... 



Bonne pratique Reutilisez le code libre quand 
il est exemplaire ! 

Le code que vous decouvrirez dans ce livre peut 
servir de base a vos futurs developpements ; 
n'hesitez surtout pas a en copier-coller des bouts 
pour vos propres besoins, voire a en recuperer des 
fonctionnalites completes si vous le souhaitez. 



En quoi cet ouvrage est-il different ? 

On se souvient tous des debuts du langage PHP 4. C'etait la belle epoque 
du Web ! PHP a certainement ete l'un des premiers langages de program- 
mation dedie au Web et surement l'un des plus simples a maitriser. 

Mais les technologies web evoluant tres vite, les developpeurs ont besoin 
d'etre en permanence a l'affut des dernieres innovations et surtout des 
bonnes pratiques. La meilleure facon d'effectuer une veille technolo- 
gique efficace est de lire des blogs d'experts, des tutoriels eprouves et 
bien evidemment des ouvrages de qualite. Cependant, pour des langages 
aussi varies que le PHP, le Python, le Java, le Ruby, ou meme le Perl, il 
est decevant de constater qu'un grand nombre de ces ouvrages presen- 
tent une lacune majeure... En effet, des qu'il s'agit de montrer des exem- 
ples de code, ils laissent de cote des sujets primordiaux, et pallient le 
manque par des avertissements de ce genre : 

• « Lors du developpement d'un site, pensez aussi a la validation et la 
detection des erreurs » ; 

• « Le lecteur veillera bien evidemment a ajouter la gestion de la 
securite » ; 

• « L'ecriture des tests est laissee a titre d'exercice au lecteur. » 

Or chacune de ces questions - validation, securite, gestion des erreurs, 
tests - est primordiale des qu'il s'agit d'ecrire du code professionnel. 
Comment ne pas se sentir, en tant que lecteur, un peu abandonne ? Si 
ces contraintes - de surcroit les plus complexes a gerer pour un deve- 
loppeur - ne sont pas prises en compte, les exemples perdent de leur 
interet et de leur exemplarite ! 

Le livre que vous tenez entre les mains ne contient pas d'avertissement 
de ce type : une attention particuliere est pretee a l'ecriture du code 
necessaire pour gerer les erreurs et pour valider les donnees entrees par 
l'utilisateur. Du temps est egalement consacre a l'ecriture de tests auto- 
matises afin de valider les developpements et les comportements 
attendus du systeme. 



VI 



Symfony fournit en standard des outils permettant au developpeur de tenir 
compte de ces contraintes plus facilement et en etant parcimonieux en quan- 
tite de code. Une partie de cet ouvrage est consacree a ces fonctionnalites car 
encore une fois, la validation des donnees, la gestion des erreurs, la securite 
et les tests automatises sont ancres au cceur meme du framework - ce qui lui 
permet d'etre employe y compris sur des projets de grande envergure. 

Dans la philosophic de Symfony, les bonnes pratiques de developpement 
ont done part egale avec les nombreuses fonctionnalites du framework. 
Elles sont d'autant plus importantes que Symfony est utilise pour le 
developpement d'applications critiques en entreprise. 

Organisation de I'ouvrage 

Cet ouvrage est compose de vingt-et-un chapitres qui expliquent pas a 
pas la construction d'une application web professionnelle Open Source 
avec le framework Symfony. L'objectif de cette serie de chapitres est de 
detailler une a une les fonctionnalites qui font le succes de Symfony, 
mais aussi et surtout de montrer ce qui fait de Symfony un outil profes- 
sional, efficace et agreable a utiliser. 

Le chapitre 1 ouvre le bal avec l'installation et 1'initialisation du projet 
Jobeet. Ces premieres pages sont jalonnees en cinq parties majeures : le 
telechargement et l'installation des librairies de Symfony, la generation 
de la structure de base du projet ainsi que celle de la premiere applica- 
tion, la configuration du serveur web et enfin l'installation d'un depot 
Subversion pour le controle du suivi du code source. 

Le chapitre 2 dresse le cahier des charges fonctionnelles de l'application 
developpee au fil des chapitres. Les besoins fonctionnels majeurs de 
Jobeet y seront decrits un a un a l'aide de cas d'utilisation illustres. 

Le chapitre 3 entame veritablement les hostilites en s'interessant a la 
conception du modele de la base de donnees, et a la construction auto- 
matique de cette derniere a partir de FORM Doctrine. Lintegralite du 
chapitre sera ponctuee par de nombreuses astuces techniques et bonnes 
pratiques de developpement web. Ce chapitre s'achevera enfin avec la 
generation du tout premier module fonctionnel de l'application a l'aide 
des taches automatiques de Symfony. 

Le chapitre 4 aborde Fun des points cles du framework Symfony : 
l'implementation du motif de conception Modele Vue Controleur. Ces 
quelques pages expliqueront tous les avantages qu'apporte cette metho- 
dologie eprouvee en termes d'organisation du code par rapport a une 
autre, et sera Foccasion de decouvrir et de mettre en oeuvre les couches 
de la Vue et du Controleur. 



Le chapitre 5 se consacre quant a lui a un autre sujet majeur de 
Symfony : le routage. Cet aspect du framework concerne la generation 
des URLs propres et la maniere dont elles sont traitees en interne par 
Symfony Ce chapitre sera done l'occasion de presenter les differentes 
types de routes qu'il est possible de creer et de decouvrir comment cer- 
taines d'entre elles sont capables d'interagir directement avec la base de 
donnees pour retrouver des objets qui leur sont lies. 

Le chapitre 6 est dedie a la manipulation de la couche du Modele avec 
Symfony Ce sera done l'occasion de decouvrir en detail comment le fra- 
mework Symfony et l'ORM Doctrine permettent au developpeur de 
manipuler une base de donnees en toute simplicite a l'aide d'objets plutot 
que de requetes SQL brutes. Ce chapitre met egalement l'accent sur une 
autre bonne pratique ancree dans la philosophic du framework Symfony : 
le remaniement du code. Le but de cette partie du chapitre est de sensibi- 
liser le lecteur a l'interet d'une constante remise en question de ses deve- 
loppements - lorsqu'il a la possibilite de l'ameliorer et de le simplifier. 

Le chapitre 7 est une compilation de tous les sujets abordes precedem- 
ment puisqu'il y est question du modele MVC, du routage et de la mani- 
pulation de la base de donnees par i'intermediaire des objets. Toutefois, 
les pages de ce chapitre introduisent deux nouveaux concepts : la simpli- 
fication du code de la Vue ainsi que la pagination des listes de resultats 
issus d'une base de donnees. De la meme maniere qu'au sixieme cha- 
pitre, un remaniement regulier du code sera opere afin de comprendre 
tous les benefices de cette bonne pratique de developpement. 

Le chapitre 8 presente a son tour un sujet encore meconnu des deve- 
loppeurs professionnels mais particulierement important pour garantir la 
qualite des developpements : les tests unitaires. Ces quelques pages pre- 
sentent tous les avantages de l'ajout de tests automatiques pour une 
application web, et expliquent de quelle maniere ces derniers sont parfai- 
tement integres au sein du framework Symfony via la librairie Open 
Source Lime. 

Le chapitre 9 fait immediatement suite au precedent en se consacrant a 
un autre type de tests automatises : les tests fonctionnels. Lobjectif de ce 
chapitre est de presenter ce que sont veritablement les tests fonctionnels 
et ce qu'ils apportent comme garanties au cours du developpement de 
l'application Jobeet. Symfony est en effet dote d'un sous-framework de 
tests fonctionnels puissant et simple a prendre en main, qui permet au 
developpeur d'executer la simulation de 1' experience utilisateur dans son 
navigateur, puis d'analyser toutes les couches de l'application qui sont 
impliquees lors de ces scenarios. 



Pour ne pas interrompre le lecteur dans sa lancee et sa soif d'apprentissage, 
le chapitre 10 aborde l'importante notion de gestion des formulaires. Les 
formulaires constituent la principale partie dynamique d'une application 
web puisqu'elle permet a l'utilisateur final d'interagir avec le systeme. Bien 
que les formulaires soient faciles a mettre en place, leur gestion n'en 
demeure pas moins tres complexe puisqu'elle implique des notions de vali- 
dation de la saisie des utilisateurs, et done de securite. Heureusement, 
Symfony integre un sous-framework destine aux formulaires capable de 
simplifier et d'automatiser leur gestion en toute securite. 

Le chapitre 11 agrege les connaissances acquises aux chapitres 9 et 10 en 
expliquant de quelle maniere il est possible de tester fonctionnellement 
des formulaires avec Symfony Par la meme occasion, ce sera le moment 
ideal pour ecrire une premiere tache automatique de maintenance, exe- 
cutable en ligne de commande ou dans une tache planifiee du serveur. 

Le chapitre 12 est l'un des plus importants de cet ouvrage puisqu'il fait 
le tour complet d'une des fonctionnalites les plus appreciees des deve- 
loppeurs Symfony : le generateur d'interface d'administration. En quel- 
ques minutes seulement, cet outil permettra de batir un espace complet 
et securise de gestion des categories et des offres d'emploi de Jobeet. 

L'utilisateur est l'acteur principal dans une application puisque e'est lui 
qui interagit avec le serveur et qui recupere ce que ce dernier lui renvoie 
en retour. Par consequent, le chapitre 13 se dedie entierement a lui et 
montre, entre autres, comment sauvegarder des informations persis- 
tantes dans la session de l'utilisateur, ou encore comment lui restreindre 
l'acces a certaines pages s'il nest pas authentifie ou s'il ne dispose pas des 
droits d'acces necessaires et suffisants. D'autre part, une serie de rema- 
niements du code sera realisee pour simplifier davantage le code et le 
rendre testable. 

Le chapitre 14 s'interesse a une puissante fonctionnalite du sous-fra- 
mework de routage : le support des formats de sortie et l'architecture 
RESTful. A cette occasion, un module complet de generation de flux de 
syndication RSS/ATOM est developpe en guise d'exemple afin de mon- 
trer avec quelle simplicite Symfony est capable de gerer nativement dif- 
ferents formats de sortie standards. 

Le chapitre 15 approfondit les connaissances sur le framework de rou- 
tage et les formats de sortie en developpant une API de services web 
destines aux webmasters, qui leur permet d'interroger Jobeet afin d'en 
recuperer des resultats dans un format de sortie XML, JSON ou YAML. 
Lobjectif est avant tout de montrer avec quelle aisance Symfony facilite 
la creation de services web innovants grace a son architecture RESTful. 



Toute application dynamique qui se respecte comprend spontanement 
un moteur de recherche, et c'est exactement l'objectif du chapitre 16. En 
seulement quelques minutes, l'application Jobeet beneficiera d'un 
moteur de recherche fonctionnel et teste, reposant sur le composant 
Zend_Search_Lucene du framework Open Source de la societe Zend. 
C'est l'un des nombreux avantages de Symfony que de pouvoir accueillir 
simplement des composants tiers comme ceux du framework Zend. 

Le chapitre 17 ameliore 1' experience utilisateur du moteur de recherche 
cree au chapitre precedent, en integrant des composants JavaScript et 
Ajax non intrusifs, developpes au moyen de l'excellente librairie jQuery. 
Grace a ces codes JavaScript, l'utilisateur final de Jobeet beneficiera d'un 
moteur de recherche dynamique qui filtre et rafraichit la liste de resultats 
en temps reel a chaque fois qu'il saisira de nouveaux caracteres dans le 
champ de recherche. 

Le chapitre 18 aborde un nouveau point commun aux applications web 
professionnelles : l'internationalisation et la localisation. Grace a Symfony, 
l'application Jobeet se dotera d'une interface multilingue dontles contenus 
traduits seront geres a la fois par Doctrine pour les informations dynami- 
ques des categories, et par le biais de catalogues XLIFF standards. 

Le chapitre 19 se consacre a la notion de plug-ins dans Symfony. Les 
plug-ins sont des composants reutilisables a travers les differents projets, et 
qui constituent egalement un moyen d'organisation du code different de la 
structure par defaut proposee par Symfony. Par consequent, les pages de ce 
chapitre expliquent pas a pas tout le processus de transformation de 
l'application Jobeet en plug-in completement independant et reutilisable. 

Le chapitre 20 de cet ouvrage se consacre au puissant sous-framework 
de mise en cache des pages HTML afin de rendre l'application encore 
plus performante lorsqu'elle sera deployee en production au dernier cha- 
pitre. Ce chapitre est aussi l'occasion de decouvrir de quelle maniere de 
nouveaux environnements d'execution peuvent etre ajoutes au projet, 
puis soumis a des tests automatises. 

Enfin, le chapitre 21 cloture cette etude de cas par la preparation de 
l'application a la derniere etape decisive d'un projet web : le deploiement 
en production. Les pages de ce chapitre introduisent tous les concepts de 
configuration du serveur web de production ainsi que les outils d'auto- 
matisation des deploiements tels que rsync. 

Pour conclure, trois parties d'annexes sont disponibles a la fin de cet 
ouvrage pour en savoir plus sur la syntaxe du format YAML et sur les 
directives de parametrage de deux fichiers de configuration de Symfony 
presents dans chaque application developpee. 
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Un projet web necessite des le demarrage une plate-forme 
de developpement complete dans la mesure ou de nombreuses 
technologies interviennent et cohabitent ensemble. 
Ce chapitre introduit les notions elementaires de projet 
Symfony, d'environnements web, de configuration de serveur 
virtuel mais aussi de gestion du code source au moyen d'outils 
comme Subversion. 



Comme pour tout projet web, il est evident de ne pas se lancer tete 
baissee dans le developpement de l'application, c'est pourquoi aucune 
ligne de code PHP ne sera devoilee avant le troisieme chapitre de cet 
ouvrage. Neanmoins, ce chapitre revelera combien il est benefique et 
utile de profiter d'un framework comme Symfony seulement en creant 
un nouveau projet. 

L'objectif de ce chapitre est de mettre en place l'environnement de travail 
et d'afficher dans le navigateur une page generee par defaut par Sym- 
fony. Par consequent, il sera question de l'installation du framework 
Symfony, puis de 1'initialisation de la premiere application mais aussi de 
la configuration adequate du serveur web local. Pour finir, une section 
detaillera pas a pas comment installer rapidement un depot Subversion 
capable de gerer le controle du suivi du code source du projet. 



ASTUCE Installer une plate-forme 
de developpement pour Windows 

Des outils comme WAMP Server 2 
(www.wampserver.com) sous Windows per- 
mettent d'installer en quelques dies un environne- 
ment Apache, PHP et MySQL complet utilisant les 
dernieres versions de PHP. lis permettent ainsi de 
demarrer immediatement le developpement de 
projets PHP sans avoir a se preoccuper de l'instal- 
lation des differents serveurs. 



Remarque Beneficier des outils 
d'Unix sous Windows 

Si vous souhaitez reproduire un environnement 
Unix sous Windows, et avoir la possibility d'utiliser 
des utilitaires comme tar, gzi p ou grep, vous 
pouvez installer Cygwi n (http://cygwin.com). 
La documentation officielle est un peu restreinte, 
mais vous trouverez un tres bon guide d'installa- 
tion a I'adresse http://www.soe.ucsc.edu/ 
~you/notes/cygwin-install.html. Si vous etes 
un peu plus aventurier dans I'ame, vous pouvez 
meme essayer Windows Services for Unix a 
I'adresse http://technet.microsoft.com/en- 
gb/interopmigration/bb380242.aspx. 



Installer et configurer les bases du projet 

Les prerequis techniques pour demarrer 

Tout d'abord, il faut s' assurer que l'ordinateur de travail possede un envi- 
ronnement de developpement web complet compose d'un serveur web 
(Apache par exemple), d'une base de donnees (MySQL, PostgreSQL, 
ou SQLite) et bien evidemment de PHP en version 5.2.4 ou superieure. 

Tout au long du livre, la ligne de commande permettra de realiser de tres 
nombreuses taches. Elle sera particulierement facile a apprehender sur un 
environnement de type Unix. Pour les utilisateurs sous environnement 
Windows, pas de panique, puisqu'il s'agit juste de taper quelques com- 
mandes apres avoir demarre l'utilitaire cmd (Demarrer > Executer > cmd). 

Ce livre etant une introduction au framework Symfony, les notions rela- 
tives a PHP 5 et a la programmation orientee objet sont considerees 
comme acquises. 

Installer les librairies du framework Symfony 

La premiere etape technique de ce projet demarre avec l'installation des 
librairies du framework Symfony. Pour commencer, le dossier dans 
lequel figureront tous les fichiers du projet doit etre cree. Les utilisateurs 
de Windows et d'Unix disposent tous de la meme commande mkdi r 
pour y parvenir. 



Creation du dossier du projet en environnement Unix 

$ mkdi r -p /home/sfprojects/jobeet 
$ cd /home/sfprojects/jobeet 

Creation du dossier du projet en environnement Windows 

c:\> mkdi r c:\deve~lopment\sfprojects\jobeet 
c:\> cd c:\development\sfprojects\jobeet 

Une fois le repertoire du projet cree, le repertoire 1 i b/vendor/ contenant 
les librairies de Symfony doit a son tour etre construit dans le repertoire 
du projet. 

Creation du repertoire lib/vendor/ du projet 

| $ mkdi r -p /lib/vendor 

La page d'installation de Symfony (http://www.symfony-project.org/ 
installation) sur le site officiel du projet liste et compare les differentes 
versions disponibles du framework. Ce livre a ete ecrit pour fonctionner 
avec la toute derniere version 1.2 de Symfony. A l'heure oil sont ecrites 
ces lignes, la derniere version de Symfony disponible est la 1.2.5. 

La section Source Download de cette page propose un lien permettant de 
telecharger une archive des fichiers source de Symfony au format . tgz ou 
.zip. Cette archive doit etre telechargee dans le repertoire lib/vendor/ 
qui vient d'etre cree, puis decompressed dans ce meme repertoire. 

Installation des fichiers sources de Symfony dans le repertoire lib/vendor/ 

$ cd lib/vendor 

$ tar zxpf symfony-1. 2 . 5 .tgz 

$ mv symfony-1. 2 . 5 symfony 

$ rm symfony-1. 2 . 5 . tgz 

Sous Windows, il est plus facile d'utiliser l'explorateur de fichiers pour 
decompresser l'archive au format ZIP. Apres avoir renomme le reper- 
toire en symfony, la structure du projet devrait ressembler a celle-ci : 
c :\development\sf project s\jobeet\l i b\vendor\symfony. 

La configuration par defaut de PHP variant enormement d'une installa- 
tion a une autre, il convient de s'assurer que la configuration du serveur 
correspond aux prerequis minimaux de Symfony. Pour ce faire, le script 
de verification fourni avec Symfony doit etre execute depuis la ligne de 
commande. 



ASTUCE Eviter les chemins 
contenant des espaces 

Pour des raisons de simplicity et d'efficacite dans 
la ligne de commande Windows, il est vivement 
recommande aux utilisateurs d'environnements 
Microsoft d'installer le projet et d'executer les 
commandes Symfony dans un chemin qui ne con- 
tient aucun espace. Par consequent, les repertoires 
Documents and Settings ou encore My 
Documents sont a proscrire. 



Verification de la configuration du serveur 



$ cd . ./■ ■ 

$ php lib/vendor/symfony/data/bin/check_configuration.php 

En cas de probleme, le script rapportera toutes les informations neces- 
saires pour corriger l'erreur. II faut egalement executer ce script depuis le 
navigateur web puisque la configuration de PHP peut etre differente en 
fonction des deux environnements. II suffit pour cela de copier le script 
quelque part sous la racine web et d'acceder a ce fichier avec le naviga- 
teur. II ne faut pas oublier ensuite de le supprimer une fois la verification 
terminee. 

$ rm web/check_configuration.php 



******************************** 

* * 

* symfony requirements check * 



php.ini used by PEP: /apache2/php/etc/php.ini 



** Mandatory requirements 



Figure 1-1 

Resultat du controle 
la configuration du serveur 



OK 
OK 



requires PHP >- 5.2.4 

php.ini: requires zend . zei_compatibility_mode set to off 



** Optional checks 



OK PDO 

OK PDO 

OK PHP- 

[[WARNING]] XSL 



OK 
OK 
OK 
OK 
OK 
OK 
OK 
OK 
OK 



can 
can 
can 
car. 
h a s 
php 
Php 
Php 
Php 



is installed 

has some drivers installed: sqlite2, sqlite, mysql 
XML module installed 
module installed 

Install the XSL module (recommended for Propel) *** 

use token_get_all ( ) 

use mb_strlen() 

use iconv ( ) 

use utf 8_decode ( ) 

a PHP accelerator 

ini: short_open_tag set to off 

ini: magic_quotes_gpc set to off 

ini: register_globals set to off 

ini: session. auto start set to off 



Une fois la configuration du serveur validee, il ne reste plus qua verifier 
que Symfony fonctionne correctement en ligne de commande en utili- 
sant le script symfony pour afficher la version du framework. Attention, 
cet executable prend un V majuscule en parametre. 

$ php lib/vendor/symfony/data/bin/symfony -V 

Sous Windows : 
c:> cd . .\. . 

c:> php 1 i b\vendor\symfony\data\bi n\symfony -V 



Lexecution du script symfony sans parametre donne l'ensemble des pos- 
sibility offertes par cet utilitaire. Le resultat obtenu dresse la liste des 
taches automatisees et des options offertes par le framework pour acce- 
lerer les developpements. 

| $ php lib/vendor/symfony/data/bin/symfony 
Sous Windows : 

jj c:> php lib\vendor\symfony\data\bin\symfony 

Cet utilitaire est le meilleur ami du developpeur Symfony. II fournit de 
nombreux outils permettant d'ameliorer la productivite des activites 
recurrentes comme la suppression du cache, la generation de code, etc. 

Installation du projet 

Dans Symfony, les applications partagent le meme modele de donnees et 
sont regroupees en projet. Le projet Jobeet accueillera deux applications 
au total. La premiere, nommee frontend, est 1' application qui sera visible 
par tous les utilisateurs, tandis que la seconde, intitulee backend, est celle 
qui permettra aux administrateurs de gerer le site. 

Generer la structure de base du projet 

Pour l'instant, seules les librairies du framework Symfony sont installees 
dans le repertoire du projet, mais ce dernier ne dispose pas encore des 
fichiers et repertoires qui lui sont propres. II faut done demander a Sym- 
fony de batir toute la structure de base du projet comprenant de nom- 
breux fichiers et repertoires qui seront tous etudies au fur et a mesure des 
chapitres de cet ouvrage. La commande generate: project de l'execu- 
table symfony permet de creer ladite structure du projet. 

| $ php lib/vendor/symfony/data/bin/symfony generate : project jobeet 
Sous Windows : 

| c:\> php 1 i b\vendor\symfony\data\bi n\symfony generate : project jobeet 

La tache generate: project genere la structure par defaut des repertoires 
et cree les fichiers necessaires a un projet Symfony. Le tableau ci-dessous 
dresse la liste des differents repertoires crees. 



Tableau 1-1 Liste des repertoires par defaut d'un projet Symfony 



g Remarque Pourquoi Symfony genere-t-il 
~ autant de fichiers ? 

£■ Un des benefices d'utiliser un framework hierarchise 
~§ est de standardiser les developpements. Grace a la 
& structure par defaut des fichiers et des repertoires 
de Symfony, n'importe quel developpeur connais- 
sant Symfony pourra reprendre un projet Symfony. 
En quelques minutes, il sera a meme de naviguer 
dans le code, de corriger les bogues, ou encore 
d'ajouter de nouvelles fonctionnalites. 



Repertoire 


Description 


apps/ 


Contient toutes les applications du projet 


cache/ 


Contient les fichiers mis en cache 


config/ 


Contient les fichiers de configuration globaux du projet 


lib/ 


Contient les librairies et classes du projet 


log/ 


Contient les fichiers de logs du framework 


pi ugi ns/ 


Contient les plug-ins installed 


Test/ 


Contient les scripts de tests unitaires et fonctionnels 


web/ 


Racine web du projet, c'est-a-dire tout ce qui est accessible depuis 
un navigateur web (voir ci-dessous) 



La tache generate: project a egalement cree un raccourci symfony a la 
racine du projet Jobeet pour faciliter l'ecriture de la commande 
lorsqu'une tache doit etre executee. A partir de maintenant, au lieu d'uti- 
liser le chemin complet pour executer la commande symfony, il suffira 
d'utiliser le raccourci symfony. 



ASTUCE Utiliser ('executable 
a la racine du projet 

Le fichier symfony est executable, les utilisateurs 
d'Unix peuvent remplacer chaque occurrence php 
symfony par ./symfony des maintenant. 
Pour Windows, il faut d'abord copier le fichier 
symfony.bat dans le projet et utiliser 
symfony a la place de php symfony. 
c:\> copy lib\vendor\symfony\data 
\bin\symfony.bat . 



Generer la structure de base de la premiere application 
frontend 

A present, l'objectif est de generer la structure de base de la premiere 
application frontend du projet. Celle-ci sera presente dans le repertoire 
apps/ genere juste avant. Une fois de plus, il convient de faire appel a 
I'executable symfony afin d'automatiser la generation des repertoires et 
des fichiers propres a chaque application. 

$ php symfony generate :app --escapi ng-strategy=on 
--csrf-secret="Unique$ecret" frontend 

Une fois de plus, la tache generate :app cree la structure par defaut des 
repertoires de l'application dans le dossier apps/f rontend/. 

Tableau 1-2 Liste des repertoires par defaut d'une application Symfony 



Remarque 


Repertoire 


Description 


Execution des commandes Symfony 


config/ 


Contient les fichiers de configuration de l'application 


Toutes les commandes Symfony doivent etre exe- 
cutes depuis le repertoire racine du projet, sauf si 
le contraire est clairement indique. 


lib/ 


Contient les librairies et classes de l'application 


modul es/ 


Contient le code de l'application (MVC) 




tempi ates/ 


Contient les templates principaux 
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Lorsque la tache generate :app a ete appelee, deux options dediees a la 
securite lui ont ete passees en parametres. Ces deux options permettent 
d'automatiser la configuration de 1' application a sa generation. 

• --escapi ng-strategy : cette option active les echappements pour 
prevenir des attaques XSS. 

• --csrf-secret : cette option active la generation des jetons de session 
des formulaires pour prevenir des attaques CSRF. 

En passant ces deux options a la tache, les futurs developpements qui seront 
realises tout au long de cet ouvrage seront desormais proteges des vulnera- 
bilites les plus courantes sur le web. Le framework Symfony se charge auto- 
matiquement de prendre les mesures de securite a la place du developpeur 
pour lui eviter de se soucier de ces problematiques recurrentes. 

Configuration du chemin vers les librairies de Symfony 

La commande symfony -V permet de connaitre la version du framework 
installee pour le projet, mais elle donne egalement le chemin absolu vers 
le repertoire des librairies de Symfony qui se trouve aussi dans le fichier 
de configuration config/ProjectConfiguration. class. php. 

requi re_once ' /Use rs/f abi en/wo rk/symf ony/dev/1 . 2/1 i b/autol oad/ 
sfCoreAutoload. class. php' ; 

Le probleme avec ce chemin absolu autogenere est qu'il n'est pas por- 
table puisqu'il correspond exclusivement a la configuration de la 
machine courante. Par consequent, il convient de le changer au profit 
d'un chemin relatif, ce qui assurera le portage de tout le projet d'une 
machine a une autre sans avoir a modifier quoi que ce soit pour que tout 
fonctionne. 

requi re_once di rname( FILE ) . ' / . ./I i b/vendor/symfony/1 i b/ 

autol oad/sf CoreAutol oad . cl ass . php " ; 

Decouvrir les environnements emules par Symfony 

Le repertoire web/ du projet contient deux fichiers crees automatique- 
ment par Symfony a la generation de Implication frontend : index. php 
et f rontend_dev.php. Ces deux fichiers sont appeles contrdleurs frontaux 
ou front controllers en anglais. Les deux termes seront employes dans cet 
ouvrage. Ces deux fichiers ont pour objectif de traiter toutes les requetes 
HTTP qui les traversent et qui sont a destination de Implication. La 
question qui se pose alors est la suivante : Pourquoi avoir deux contrd- 
leurs frontaux alors qu'une seule application a ete generee ? 



Culture Web En savoir plus 
sur les attaques XSS et CSRF 

Les attaques XSS (Cross Site Scripting), et les 
attaques CSRF (Cross Site Request Forgeries 
ou Sea Surf), sont a la fois les plus repandues sur 
le web mais aussi les plus dangereuses. Par conse- 
quent, il est important de bien les connaitre pour 
savoir s'en premunir efficacement. L'encyclopedie 
en ligne Wikipedia consacre une page dediee a 
chacune d'elles aux adresses suivantes : 
http://en.wikipedia.org/wiki/Cross- 
site_scripting 

http://en.wikipedia.org/wiki/Cross- 
Site_Request_Forgery 



Quels sont les principaux environnements en developpement web ? 

Les deux fichiers pointent vers la meme application a la difference qu'ils 
prennent chacun en compte un environnement different. Lorsque Ton 
developpe une application, a 1' exception de ceux qui developpent direc- 
tement sur le serveur de production, il est necessaire d'avoir plusieurs 

environnements d'execution cloisonnes : 

• / 'environnement de developpement est celui qui est utilise par les deve- 
loppeurs quand ils travaillent sur 1' application pour lui ajouter de 
nouvelles fonctionnalites ou corriger des bogues ; 

• V environnement de test sert quant a lui a soumettre l'application a des 
series de tests automatises pour verifier quelle se comporte bien ; 

• V environnement de recette est celui qu'utilise le client pour tester 
l'application et rapporter les bogues et fonctionnalites manquantes 
aux chefs de projet et developpeurs ; 

• V environnement de production est l'environnement sur lequel les utili- 
sateurs finaux agissent. 

Specificites de l'environnement de developpement 

Qu'est-ce qui rend un environnement unique ? Dans l'environnement de 
developpement par exemple, l'application a besoin d'enregistrer tous les 
details de chaque requete afin de faciliter le debogage, tandis que le sys- 
teme de cache des pages est desactive etant donne que les changements 
doivent etre visibles immediatement. 



Figure 1-2 

Affichage des informations de debogage 
en environnement de developpement 



500 | Internal Server Error | Exception 
Foo exception 

stack trace 

1. at() 

in SF_R0OT_DIR/apps/frontend/modules/job/actions/actipns. class. php line 15 ^ 

12. { 

13. public function execuLelndex ( sf UebRequest SrequesL] 
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15. throw new Exception (' Foo exception'); 

16. $this->jobeel_job_list - Jobeet JobPeer ::doSelect<new Crileria((); 

17. > 
18. 

at job Actio ns->executel ndex( objc cti'ctW'cb Request' )) 

in SF_SYMFONY_UB_DIR/acbon/sfAcbons,d3SS.php line 53 ^ 

at sfActions->execute(otyecc('sfWebRequest')) 

in SF_SYMFONY_UB_DIR/filter/sfExecutionFilter.dass.php line 90 ^ 

at sfExecutionFilter->executeAction(oiyect('jobActions')) 

in SF_SYMFONY_UB_DIR/filter/sfExecubonFi!ter.c!ass.php line 76 „, 

at sfExocutionFMter->handleAclion(oty'ect('sfFilterChain'), o£y"ect('jobActions')) 

in SF_SYMFONY_UB_DIR/fiIter/sfExecutionniter.ctass.php line 42 m 



Cet environnement est done optimise pour les besoins du developpeur 
puisqu'il lui rapporte toutes les informations techniques dont il a besoin 



pour travailler dans de bonnes conditions. Le meilleur exemple est bien sur 
lorsqu'une exception PHP survient. Pour aider le developpeur a deboguer 
le probleme rapidement, le framework Symfony lui affiche dans le naviga- 
teur le message d'erreur avec toutes les informations qu'il dispose concer- 
nant la requete executee. La capture d'ecran precedente en temoigne. 

Specificites de I'environnement de production 

Sur I'environnement de production, la difference provient du fait que le 
cache des pages doit bien sur etre active, et que l'application est confi- 
gured de telle sorte quelle affiche des messages d'erreur personnalises 
aux utilisateurs finaux a la place des exceptions brutes. En d'autres 
termes, I'environnement de production doit etre optimise pour repondre 
aux problematiques de performance et favoriser 1' experience utilisateur. 
La capture d'ecran ci-dessous donne le resultat de la meme requete, exe- 
cutee precedemment en environnement de developpement, sur I'envi- 
ronnement de production. 
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Oops! An Error Occurred 

The server returned a '500 Internal Server Error". 



Something is broken 

Please e-mail us at [email] and let us know what you were doing when this 
error occurred. We will fix it as soon as possible. Sorry for any 
inconvenience caused. 

What's next 

Back to previous page 
Go to Homep age 



Figure 1-3 

Affichage de la page d'erreur par defaut de 
Symfony en environnement de production 



Un environnement Symfony est un ensemble unique de parametres de 
configuration. Le framework Symfony est livre par defaut avec trois 
d'entre eux : dev, test, et prod. Au cours du chapitre 20, il sera presente 
comment creer de nouveaux environnements tel que celui de la recette. 
Si Ton ouvre les differents fichiers des controleurs frontaux pour les 
comparer, on constate que leur contenu est strictement identique, a 
l'exception du parametre de configuration dedie a I'environnement. 



ASTUCE Creer de nouveaux 
environnements 



Contenu du contrdleur frontal web/index.php 



<?php 



Declarer un nouvel environnement Symfony est 
aussi simple que de creer un nouveau controleur 
frontal. Plusieurs chapitres et annexes de cet 
ouvrage presentent comment modifier la configu- 
ration pour un environnement donne. 



requf re_once(di rname( FILE ) . '/■ ./config/ 

Pro j ectConf i gu rati on . cl ass . php ' ) ; 



$configuration = 



Pro j ectConf i gu rati on : : getAppI i catf onConf f gu rati on ( ' f rontend ' , 
'prod' , false) ; 

sf Context : : createInstance($conf f guration)->di spatchQ ; 



Les sections qui suivent s'interessent a la configuration du serveur web 
afin que celle-ci convienne parfaitement aux besoins d'un projet Sym- 
fony en termes de securite et de bonnes pratiques. Deux methodes de 
configuration du serveur sont presentees. La premiere explique ce qu'il 
ne faut absolument pas faire, tandis que la seconde montre la bonne 
maniere de proceder. 

Methode 1 : configuration dangereuse a ne pas 
reproduire 

Dans la section precedente, un repertoire complet a ete cree pour 
heberger l'ensemble du projet Jobeet. Si ce dernier a ete construit 
quelque part sous la racine web du serveur, alors il est desormais acces- 
sible entierement depuis un navigateur web. 

Bien sur, comme il n'y a aucune configuration et que c'est tres facile a 
mettre en ceuvre, cela signifie aussi que ce n'est pas la meilleure maniere 
de proceder... Pour s'en convaincre, il suffit d'essayer d'acceder au 
fichier config/databases .yml depuis le navigateur pour comprendre les 
consequences qui peuvent etre provoquees avec ce type d'attitude pares- 
seuse. En effet, si un utilisateur malintentionne decouvre que le site web 
est developpe avec Symfony, il aura alors acces a de nombreux fichiers de 
configuration sensibles en lecture... 

II est done important de garder a l'esprit de ne jamais utiliser ce type de 
configuration sur un serveur de production, et ainsi de preferer l'etape de 
configuration decrite a la section suivante. En effet, cette derniere pre- 
sente pas a pas comment configurer proprement le serveur web pour un 
projet Symfony. 



Configurer le serveur web 
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Methode 2 : configuration sure et recommandee 



Une bonne pratique de developpement web consiste a placer sous la racine 
web uniquement les fichiers qui ont veritablement besoin d'etre atteints 
depuis un navigateur : les feuilles de styles en cascade (CSS), les scripts 
JavaScript, les animations Flash ou encore les images. Bien sur, par defaut, 
ces fichiers sont stockes sous le repertoire web/ du projet Symfony. 

Ce repertoire contient d'autres sous-dossiers dedies aux ressources web 
(ess/ et images/) ainsi que les deux controleurs frontaux. Ces derniers 
sont les seuls fichiers PHP qui ont vocation a se trouver sous la racine 
web du serveur. Tous les autres fichiers PHP peuvent etre caches du 
navigateur, ce qui est plus que conseille d'un point de vue securite. 

Creation d'un nouveau serveur virtue! pour Jobeet 

A present, il est temps de changer la configuration par defaut du serveur 
Apache pour rendre le nouveau projet accessible sur Internet. Pour cela, 
il suffit de localiser et d'ouvrir le fichier de configuration http . conf et 
d'y ajouter a la fin les parametres de configuration suivants. 

Definition de la configuration du serveur virtuel de Jobeet 

# Be sure to only have this line once in your configuration 
NameVirtualHost 127.0.0.1:8080 

# This is the configuration for Hobeet 
Listen 127.0.0.1:8080 

<VirtualHost 127.0.0.1:8080> 

DocumentRoot "/nome/sfprojects/jobeet/web" 

Di rectorylndex index. php 

<Di rectory "/home/sfprojects/jobeet/web"> 

AllowOverride All 

Allow from All 
</Di rectory> 

Alias /sf /home/sfprojects/jobeet/lib/vendor/symfony/data/web/sf 
<Di rectory "/home/sfprojects/jobeet/lib/vendor/symfony/data/web/sf"> 

AllowOverride All 

Allow from All 
</Di rectory> 
</VirtualHost> 

Cette configuration indique au serveur Apache qu'il faut ecouter le port 
8080 de la machine. Par consequent, le site Internet de Jobeet sera acces- 
sible a FURL suivante : http://localhost:8080/. Le port peut etre modifie par 
un nombre strictement superieur a 1 024 etant donne qu'il ne requiert 
pas de droits d'administrateur. 



Configuration 
La directive de configuration Alias 

L'alias /sf autorise I'acces aux images et fichiers 
JavaScript dont ont besoin pour s'afficher la page 
par defaut de Symfony et la barre de debogage. 
Sur les environnements Windows, la valeur de la 
directive Alias doit etre remplacee par quelque 
chose du genre : 

Alias /sf 

"c:\development\sfprojects\jobeet\li 

b\vendor\symfony\data\web\sf " 

Et /home/sfprojects/jobeet/web 

devrait etre remplace au profit de : 

c:\development\sfprojects\jobeet\web 
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Configuration Configurer un nom de domaine pour I'application 



ASTUCE 

Profiter de la reecriture d'URL d'Apache 

Si le module mod_rewrite d'Apache est ins- 
talls sur le serveur web local, le nom du controleur 
frontal index, php/ peut etre retire de I'URL. 
Ceci est rendu possible grace aux regies de reecri- 
ture d'URL configurees dans le fichier web/ 
. htaccess. 



Remarque Configurer Jobeet sur un serveur 
Microsoft Windows IIS 

[.'installation et la configuration d'un projet Sym- 
fony est legerement differente sur les serveurs IIS 
des environnements Windows. Le tutoriel figurant 
a I'adresse http://www.symfony-project.org/ 
cookbook/1_0/en/web_server_iis explique pas 
a pas comment configurer Symfony sur ce type de 
serveur. 



Pour les administrateurs de la machine, il est preferable de configurer des serveurs virtuels 
plutot que d'ouvrir un nouveau port a chaque fois qu'un nouveau projet demarre. Au lieu 
de choisir un port et d'ajouter un ecouteur supplementaire, il vaut mieux trouver un nom 
de domaine et I'ajouter a la directive de configuration Serve rName. 
# This is the configuration for Jobeet 
<VirtualHost 127.0.0.1:80> 
ServerName jobeet. localhost 
<!-- same configuration as before --> 
</Vi rtualHost> 

Le nom de domaine jobeet. local host utilise dans la configuration d'Apache doit 
etre declare localement. Pour les environnements Linux, cela se passe dans le fichier 
/ect/hosts, tandis que pour Windows XP, ce fichier se trouve dans le repertoire 
C:\wINDOWS\system32\drivers\etc\. 

La configuration du nom de domaine consiste a ajouter cette ligne supplementaire au 
fichier hosts. 
127.0.0.1 jobeet. localhost 



Tester la nouvelle configuration d'Apache 

Pour tester cette nouvelle configuration, le serveur Apache doit d'abord 
etre redemarre afin de recharger les nouveaux parametres de configura- 
tion. II ne reste alors plus qua ouvrir le navigateur web et verifier que le 
controleur frontal i ndex . php est bien accessible sur le web. 

Pour ce faire, il suffit d'appeler l'une des deux URLs suivantes en fonc- 
tion de la configuration choisie precedemment pour Apache : http:// 
localhost:8080/index.php/ ou http://jobeet.localhost/index.php/. La page 
d'accueil par defaut devrait apparaitre a l'ecran confirmant deux choses : 
d'une part que le serveur virtuel de Jobeet fonctionne, et d'autre part que 
l'alias /sf est bien configure puisque le navigateur est capable de recu- 
perer les ressources web de la page. 

II est egalement possible d'acceder a I'application en environnement de 
developpement en utilisant l'URL suivante : http://jobeet. localhost/ 
frontend_dev.php/. La barre de debogage de Symfony devrait s'afficher dans 
Tangle superieur droit de la fenetre du navigateur, incluant avec elle de 
petits icones qui prouvent que l'alias /sf est convenablement configure. 

La barre de debogage de Symfony est presente sur chaque page en envi- 
ronnement de developpement et donne au developpeur Faeces a de nom- 
breuses informations en cliquant sur les differents onglets. Parmi elles 
figurent la configuration courante de I'application, les traces de logs 
enregistres pour la requete executee, les requetes SQL executees sur la 
base de donnees, le temps de generation de la page ainsi que la quantite 
de memoire utilisee. 
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Symfony Project Created 

Congratulations! You have successfully created your symfony project. 



Project setup successful 

This project uses the symfony libraries. If you see no image in this page, 
you may need to configure your web server so that it gains access to the 
Bymfony_data/web/sf / directory. 

This is a temporary page 

This page is part of the symfony default module. It will disappear as soon 
as you define a homepage route in your routing. yml. 

What's next 

0 Create your data model 

^ Customize the layout of the generated templates 
Learn more from the online documentation 



Figure 1-4 

Page d'accueil par defaut d'un projet Symfony 
en environnement de production 
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Symfony Project Created 

Congratulations! You have successfully created your symfony project. 



Project setup successful 

This project uses the symfony libraries. If you see no image in this page, 
you may need to configure your web server so that it gains access to the 
symfony_data/web/sf / directory. 

This is a temporary page 

This page is part of the symfony default module. It will disappear as soon 
as you define a homepage route in your routing. yml. 

What's next 

B Create your data model 

n** Customize the layout of the generated templates 
Learn more from the online documentation 



Figure 1-5 

Page d'accueil par defaut d'un projet Symfony 
en environnement de developpement 
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Contrdler le code source avec Subversion 



ASTUCE Utiliser un service gratuit en ligne 
de suivi du code source 

Lorsqu'il est impossible d'avoir acces a un depot 
Subversion, des solutions alternatives existent. En 
effet, des services gratuits en ligne comme Google 
Code ou GIT Hub permettent aux developpeurs de 
se creer gratuitement leur propre depot de code. 



Quels sont les avantages d'un gestionnaire de versions ? 

C'est une bonne pratique d'utiliser un logiciel de controle de versions des 
fichiers source lorsque Ton developpe une application web. En effet, 
l'utilisation de tels logiciels de suivi de versions assure aux developpeurs 
de nombreux avantages comme : 

• travailler avec confiance puisqu'il n'y a plus aucun risque de perdre le 
moindre fichier source du projet etant donne que Subversion sauve- 
garde tout ; 

• revenir a une version anterieure si un changement casse une portion 
de code quelconque ; 

• travailler efficacement a plusieurs sur le meme projet en evitant les 
conflits ; 

• avoir acces a toutes les versions successives de l'application. 

Cette derniere section decrit comment utiliser Subversion avec Symfony. 
Les utilisateurs d'un autre outil de suivi de versions tels que CVS ou 
GIT pourront s'inspirer de la demarche presentee ici pour l'adapter a 
leur logiciel de controle de code source. Cette nouvelle etape considere 
qu'un serveur Subversion est deja installe sur la machine et configure 
pour etre accessible depuis le protocole HTTP. Par consequent, seul le 
processus de creation du depot Subversion est decrit. 

Installer et configurer le depot Subversion 

La premiere etape d'installation d'un depot Subversion consiste d'abord 
a creer un repertoire dedie au projet Jobeet dans le depot global du ser- 
veur Subversion. 

$ svnadmin create /path/to/jobeet/repository 

Puis, sur la machine, la structure de base du depot Subversion doit etre 
creee. Celle-ci inclut entre autres les repertoires pour gerer le tronc, les 
branches et les tags du projet. Tout le cycle de vie du projet Jobeet se 
passera dans le tronc du depot. 

$ svn mkdi r -m "created default directory structure" 
http ://svn . exampl e . com/jobeet/trunk 
http : //svn . exampl e . com/jobeet/tags 
http : //svn . exampl e . com/jobeet/branches 
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II convient ensuite d'extraire le contenu vide du repertoire trunk/ a l'aide 
de la commande svn checkout. 

$ cd /home/sfprojects/jobeet 

$ svn co http://svn.example.com/jobeet/trunk/ . 

L'etape suivante consiste a vider le contenu des repertoires cache/ et 
log/ du projet etant donne qu'ils n'ont aucun interet a etre presents dans 
le depot Subversion. 

$ rm -rf cache/- log/* 

A present, il faut s'assurer que les permissions en ecriture sont bien defi- 
nies sur les repertoires cache/ et log/ afin que le serveur web puisse 
ecrire dans chacun d'eux. 

j $ chmod 777 cache/ log/ 

L'ajout des fichiers dans le depot peut maintenant etre effectue a l'aide 
de la commande svn add. Les fichiers ne sont pas encore envoyes au ser- 
veur Subversion. lis sont juste marques comme prets a etre envoyes et 
sauvegardes dans le depot. 

j $ svn add * 

Etant donne qu'aucun fichier ne devra etre enregistre dans les repertoires 
cache/ et log/ du depot, il convient d'ajouter le contenu de ces reper- 
toires a la liste de fichiers ignores par Subversion. 

$ svn propedit svn: ignore cache 

L'editeur de texte par defaut configure pour SVN devrait se lancer. Sub- 
version doit absolument ignorer tout le contenu de ce repertoire. Par 
consequent, il suffit de saisir le caractere etoile dans l'editeur de texte. 



Pour valider la modification, le fichier doit etre sauvegarde et l'editeur de 
texte ferme. Cette operation doit a son tour etre repetee pour le reper- 
toire 1 og/. 

J $ svn propedit svn:ignore log 

De la meme maniere, le caractere etoile doit etre saisi. 



II ne reste finalement plus qua valider tous ces changements et a les 
envoyer au serveur Subversion afin qu'il se charge de les sauvegarder et 
de les versionner. Pour ce faire, un simple appel a la commande svn 
import suffit comme le montre le code ci-dessous. 

$ svn import -m "made the initial import" 
. http : //svn . exampl e . com/jobeet/trunk 



ASTUCE Gerer un depot Subversion a I'aide d'un client graphique 

Les utilisateurs de Windows peuvent s'appuyer sur I'excellent logiciel TortoiseSVN pour gerer 
leurs depots Subversion en toute simplicite dans un explorateur de fichiers graphique. 



En resume... 

Ce tout premier chapitre s'acheve ici. Bien qu'il n'ait pas encore ete veri- 
tablement question de Symfony, le projet Jobeet a pu neanmoins 
demarrer dans de bonnes conditions et repose deja sur des bases solides. 
En effet, la premiere application Symfony generee est deja securisee par 
defaut, le serveur web est configure proprement, un depot Subversion a 
ete installe afin de suivre les evolutions du code source du projet, et enfin 
d'autres bonnes pratiques de developpement web ont ete presentees. Par 
consequent, le projet est pret a recevoir ses premieres lignes de code. 

Le chapitre qui suit ne s'interesse pas encore au code puisqu'il sera uni- 
quement question d'y reveler les differentes specifications fonctionnelles 
du projet qui seront implementees a partir du troisieme chapitre. 

L'ensemble du projet Jobeet a ete versionne dans un depot Subversion 
(http://svn.jobeet.org/doctrine/) du site officiel de Symfony. Ce depot contient 
le code source de 1' application a chaque chapitre, ce qui permet de le recu- 
perer a himporte quelle etape de son avancee. Par exemple, pour recuperer 
tous les fichiers source du premier chapitre, il suffit d'extraire la version 
marquee rel ease_day_01 a I'aide de la commande svn checkout. 

$ svn co http://svn.jobeet.org/doctrine/tags/reiease_day_01/ jobeet/ 
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L'etude de cas 



MOTS-CLES 



Tout projet professionnel doit demarrer avec une etude 

prealable des besoins fonctionnels, menant ensuite 

a l'elaboration de documents de specifications techniques. 

Ce second chapitre est a pour seul objectif de presenter les 
besoins fonctionnels de l'etude de cas qui sera developpee tout 
au long de cet ouvrage, en ayant recours a des descriptions 
simples et des maquettes graphiques d'interface. 



► Framework Symfony 

► maquette d'interface graphique 

► Etude des besoins fonctionnels 



Tout projet professionnel informatique qui se respecte est elabore sui- 
vant un planning jalonne en plusieurs etapes. Parmi ces etapes figurent 
obligatoirement 1' analyse des besoins fonctionnels du commanditaire 
ainsi que la redaction de specifications techniques. Ces deux etapes sont 
bien evidemment menees par les equipes decisionnelles en amont du 
developpement du projet afin de valider ce que les equipes de production 
devront realiser pour satisfaire les besoins du client et des utilisateurs 
finaux de l'application. 

L'etude de cas qui sera developpee pas a pas au cours de cet ouvrage 
beneficie elle aussi de specifications fonctionnelles, dans le but de deter- 
miner l'ensemble des fonctionnalites majeures de l'application. Par con- 
sequent, ce chapitre se destine exclusivement a presenter la liste des 
besoins fonctionnels a l'aide de maquettes d'interface graphique. Deux 
sections distinctes seront specifiers : l'application grand public, le fron- 
tend et l'interface d'administration du site, le backend. 



A la decouverte du projet... 

Le premier chapitre de cet ouvrage n'etait resolument pas oriente vers le 
developpement des premieres lignes de code PHP, puisqu'il s'agissait de 
preparer le terrain en installant l'environnement de developpement, puis 
de creer un projet vide avec Symfony. Les premiers pas avec la ligne de 
commande de Symfony ont egalement permis de s' assurer que le projet, 
qui sera devoile dans les sections suivantes, repose deja sur des bases 
solides et qu'il est convenablement configure avec des parametres de 
securite par defaut. En progressant un peu au-dela des explications du 
premier chapitre, le lecteur aura surement remarque l'ecran de felicita- 
tions de Symfony qui confirme que le projet est pret a demarrer. 

A l'heure oil cet ouvrage est redige, une crise economique touche toute la 
planete depuis plusieurs mois. Le licenciement des salaries ne cesse 
quant a lui de croitre dans de nombreux secteurs d'activite... Heureuse- 
ment les developpeurs Symfony ont la chance de ne pas veritablement se 
sentir concernes par la crise, et c'est probablement pour cette raison que 
l'apprentissage de Symfony se justifie. Neanmoins aujourd'hui, il est 
encore particulierement difficile de trouver des developpeurs Symfony 
tres competents. 

Les questions qui se posent alors sont les suivantes : ou peut-on trouver 
des developpeurs Symfony ? Et comment les developpeurs peuvent-ils 
promouvoir leurs competences avec Symfony ? 



Symfony Project Created 

Congratulations! You have successfully created your symfony project. 



Project setup successful 

This project uses the symfony libraries. If you see no image in this page, 
you may need to configure your web server so that it gains access to the 
Bymfony_data/web/si7 directory. 

This is a temporary page 

This page is part of the symfony default module. It will disappear as soon 
as you define a homepage route in your routing. yml. 

What's next 

6 Create your data model 

n*) Customize the layout of the generated templates 
Learn more from the online documentation 



Figure 2-1 

Page d'accueil par defaut 
d'un nouveau projet Symfony 



II faut pour cela trouver un gestionnaire d'offres d'emploi qui se focalise 
uniquement sur les annonces. Ce gestionnaire doit rendre possible la 
recherche des meilleures personnes qualifiers dans leur domaine d'exper- 
tise respectif. Ce cyberespace doit etre un lieu convivial oil il est facile et 
rapide de rechercher une offre d'emploi ou d'en proposer une nouvelle. 

Inutile de chercher plus loin ! Jobeet est l'application ideale pour ce genre 
de besoin. Jobeet est un logiciel Open Source de gestion d'offres 
d'emploi qui ne fait qu'une seule chose, mais qui la fait bien. II est facile 
a utiliser, a personnaliser, a faire evoluer et bien sur a embarquer dans 
d'autres applications web. Par ailleurs, il supporte nativement plusieurs 
langues, et fait bien evidemment usage des toutes dernieres technologies 
Web 2.0 innovantes afin d'ameliorer l'experience utilisateur. II fournit 
egalement des flux RSS ainsi qu'une API pour interagir avec lui par le 
biais de services web. 

Ce genre d'applications n'existe-t-il pas deja sur Internet aujourd'hui ? 
En tant qu'utilisateur, il ne sera pas difficile de trouver des gestionnaires 
d'offres d'emploi comme Jobeet sur Internet. Le plus complique est tou- 
tefois d'essayer d'en trouver un qui soit a la fois libre et disposant de 
nombreuses fonctionnalites riches comme celles qui seront developpees 
ici. Enfin, le dernier avantage de Jobeet est qu'il suffit de moins de 
24 heures pour le developper avec Symfony. Dans cet ouvrage, il est 
question de 21 chapitres a lire et a pratiquer a son rythme. . . 



ASTUCE Trouver de nouveaux developpeurs 
grace a Symfonians 

II existe depuis deja quelques annees un veritable 
outil Open Source de gestion d'offres d'emploi sur 
Internet a destination des recruteurs et deve- 
loppeurs Symfony : le site symfonians.net (http:// 
symfonians.net). 
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Decouvrir les specifications fonctionnelles 
de Jobeet 



Les differents acteurs et applications impliques 

Avant de plonger dans le code, il est important de decrire davantage les 
specificites du projet. Les sections qui suivent decrivent les fonctionna- 
lites qui seront implementees a la premiere version (iteration) de Jobeet. 
Ces fonctionnalites ont ete etablies a partir de quelques cas d'utilisation. 

Le site Internet de Jobeet possede quatre types d'acteurs : 

• Vadministrateur qui a les pleins pouvoirs sur le site Internet, c'est-a- 
dire qui peut tout y faire ; 

• Vutilisateur qui se contente de visiter le site Internet a la recherche 
d'un emploi ; 

• le posteur (ou recruteur) qui visite le site afin de poster une nouvelle 
offre d'emploi ; 

• Vajfilie qui relaie quelques offres d'emploi sur son propre site 
Internet. 

Le projet se decompose egalement en deux applications distinctes. La 
premiere est l'interface Internet grand public, appelee frontend, a partir 
de laquelle les utilisateurs interagissent. Elle leur permet entre autres de 
consulter et de deposer de nouvelles offres d'emploi, de s'inscrire et 
d'utiliser l'API de services web, ou encore de s'abonner a des flux RSS. 
Lapplication frontend est decrite dans les cas d'utilisation Fl a F7. 

La seconde application est l'interface d'administration, autrement 
denommee backend, dans laquelle les administrateurs ont la possibilite de 
gerer l'integralite des contenus dynamiques comme les utilisateurs, les 
offres d'emploi, les categories ou encore les affilies. Cette zone est bien 
evidemment securisee et strictement reservee aux utilisateurs possedant 
les droits d'acces requis pour y penetrer. Les fonctionnalites de cette 
application sont decrites dans les cas d'utilisations Bl a B4. 

Utilisation de ('application grand public : le frontend 

Scenario Fl : voir les dernieres offres en page d'accueil 

Lorsqu'un utilisateur arrive sur le site Internet de Jobeet, il decouvre une 
liste des dernieres offres d'emploi actives. Les annonces sont d'abord 
classees par categorie par ordre alphabetique croissant, puis par date de 
publication decroissante. Pour chaque annonce, seuls le type de poste, la 
societe et sa localisation sont affiches. 



Pour chaque categorie, la liste montre seulement les dix premieres offres 
et un lien permet de lister toutes les annonces pour la categorie donnee 
{se reporter au cas d'utilisation F2). 

Depuis la page d'accueil, ou tout autre page, l'utilisateur peut affiner la 
liste des offres d'emploi {cas d'utilisation F3) ou poster une nouvelle 
annonce sur le site {cas d'utilisation F5). 
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Figure 2-2 

Maquette de la page d'accueil de Jobeet pour le scenario F1 



Scenario F2 : voir les offres d'une categorie 

Lorsqu'un utilisateur clique sur le nom de la categorie ou bien sur le lien 
more jobs depuis la page d'accueil, il accede a la liste de toutes les offres 
de cette categorie, classees par date de publication decroissante. Afin de 
faciliter la navigation et l'experience utilisateur, la liste est paginee avec 
vingt annonces maximum par page. 
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Figure 2-3 

Maquette de la liste des offres 
d'une categorie pour le scenario F2 
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Scenario F3 : affiner la liste des offres avec des mots-cles 

Comme toute application web dynamique hebergeant du contenu en 
masse, il est important de faciliter la remontee d'informations a partir 
d'un moteur de recherche. 

L'utilisateur peut ainsi saisir une serie de mots-cles pour affiner sa 
recherche et reduire le nombre d'offres a celles qui correspondent le 
mieux a ses attentes. Les mots-cles saisis par ce dernier peuvent etre des 
informations issues des champs localisation, type de poste, nom de la cate- 
gorie ou encore nom de la societe. 

L'utilisation de la technologie client JavaScript assure egalement un 
meilleur confort d'utilisation et une experience utilisateur accrue en 
reduisant en temps reel la selection d'offres d'emploi a chaque fois que 
l'utilisateur tape un nouveau caractere dans le moteur de recherche. Pour 
des raisons d'accessibilite, cette fonctionnalite est developpee avec du 
code non intrusif pour garantir un fonctionnement en mode « degrade » 
lorsque le JavaScript n'est pas active sur le poste de l'utilisateur. 

Scenario F4 : obtenir le detail d'une offre 

L'utilisateur peut selectionner une offre d'emploi en cliquant sur le type de 
poste depuis la liste, afin d'obtenir l'integralite des informations la concer- 
nant. La page de details affiche les informations suivantes de l'annonce : 
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• le type de poste a pourvoir ; 

• le nom de la societe ; 

• le logo de la societe ; 

• le lien vers le site de la societe ; 

• la localisation du poste ; 

• le type de contrat (temps plein, temps partiel ou freelance) ; 

• la description du poste ; 

• et la demarche a suivre pour postuler. 



Jobeet 
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Post a 
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You've already developed websites with symfony and you want to work with 
Open-Source technologies. You have a minimum of 3 years experience in web 
development with PHP or Java and you wish to participate to development of 
Web 2.0 sites using the best frameworks available. 

How to apply? 

Send your resume to fabien.potencier [at] sensio.com 



Aboutjobeet | Full RSS Feed | Jobeet API | Affiliates 



Figure 2-4 

Maquette du detail d'une offre d'emploi pour le scenario F4 



Scenario F5 : poster une nouvelle annonce 

Un utilisateur peut librement ajouter une nouvelle offre d'emploi au site 
Internet. Cette derniere se compose de plusieurs types d'information, 
dont certains sont obligatoires : 

• le nom de la societe ; 

• le type de contrat (temps plein, temps partiel ou freelance) ; 

• le logo de la societe (optionnel) ; 

• l'URL du site de la societe (optionnel) ; 

• le type de poste ; 
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la localisation ; 

le nom de la categorie (choisi d'apres une liste de categories possibles) ; 

la description de l'offre (les adresses e-mails et les URLs sont auto- 

matiquement transformees en liens cliquables) ; 

la demarche a suivre pour postuler (les adresses e-mails et les URLs 

sont automatiquement transformees en liens cliquables) ; 

le mode de diffusion qui indique si l'offre peut etre publiee ou pas sur 

les sites affilies ; 

l'adresse e-mail de l'auteur de l'annonce. 



Figure 2-5 

e du formulaire de creation d'une 
nouvelle offre pour le scenario F5 
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Poster une nouvelle offre d'emploi sur Jobeet ne requiert pas de crea- 
tion de compte utilisateur. Le processus d'ajout d'une nouvelle 
annonce est simple et se realise en deux temps. Tout d'abord, i'utili- 
sateur remplit le formulaire avec toutes les informations obligatoires 
pour decrire l'offre, puis le valide en previsualisant la page de 
l'annonce finale. 



Bien qu'un utilisateur n'ait pas de compte d'abonne sur l'application, il 
reste en mesure de modifier son annonce plus tard grace a une URL spe- 
cifique dans laquelle figure un jeton unique qui lui est attribue a la crea- 
tion definitive de l'offre. 

Chaque annonce dispose d'une duree de vie de trente jours, configurable 
par l'administrateur du site (se refer er au cas d' utilisation B2). L'utilisateur 
peut quant a lui revenir pour reactiver ou prolonger la validite de son 
offre pour une nouvelle periode de trente jours a condition que celle-ci 
arrive a expiration dans moins de cinq jours. 

Scenario F6 : s'inscrire en tant qu'affilie pour utiliser I'API 

Un utilisateur a besoin de postuler pour devenir un affilie et etre autorise 
a manipuler l'API de Jobeet. Pour postuler a l'API, il doit d'abord ren- 
seigner les informations suivantes : 

• son identite ; 

• son adresse e-mail ; 

• l'adresse de son site Internet. 

Le compte de l'affilie est soumis a la validation expresse des administra- 
teurs (se referer au cas d'utilisation B4). Une fois active, l'affilie recoit par e- 
mail le jeton unique qui lui permet d'utiliser l'API. Enfin, quand l'affilie 
s'abonne au service, il peut aussi choisir un sous-ensemble d'annonces a 
afficher sur son site Internet en selectionnant une liste de categories dispo- 
nibles dans lesquelles figurent les dernieres offres a remonter. 

Scenario F7 : l'affilie recupere la liste des dernieres offres actives 

Un affilie peut recuperer la liste des dernieres offres d'emploi actives en 
appelant l'API a partir de son jeton d'affilie. La liste peut etre retournee au 
choix au format XML, JSON ou bien encore YAML. Cette liste contient 
alors l'ensemble des informations publiques disponibles d'une annonce. 

Utilisation de Pinterface d'administration : le backend 

Scenario Bl : gerer les categories 

Un administrateur est capable de gerer l'ensemble des categories du site 
Internet. II dispose d'une page lui permettant de lister toutes les catego- 
ries disponibles ainsi que d'un ecran lui permettant de creer ou d'editer 
une categorie existante. L'application Jobeet etant prevue pour supporter 
le francais et l'anglais, les formulaires de creation et d'edition des catego- 
ries embarquent les champs de traduction pour chaque langue du site. 



Scenario B2 : gerer les offres d'emploi 

Un administrateur dispose d'une interface d'administration complete des 
offres d'emploi publiees sur Jobeet. Un ecran de gestion lui permet de lister 
l'ensemble des annonces classees par date de publication decroissante. 

Cette liste se presente sous la forme d'un tableau dont chaque ligne 
represente une offre. Certains en-tetes du tableau sont cliquables afin de 
modifier le classement et l'ordre des offres. D'autre part, la liste est 
paginee avec dix resultats par page et un formulaire de filtres permet de 
l'affiner en effectuant des recherches sur certains criteres predefinis. 

Chaque offre d'emploi dispose de ses propres actions qui permettent a 
l'administrateur de l'editer, de la supprimer ou encore de la prolonger 
dans le temps. Ces operations, a 1' exception de la fonction d'edition, sont 
egalement disponibles sur un lot d'offres selectionnees au moyen de 
cases a cocher. 

Enfin, une action globale permet a l'utilisateur de nettoyer la base de 
donnees des offres d'emploi perimees depuis un certain nombre de jours 
ou qui n'ont jamais ete activees. 

Scenario B3 : gerer les comptes administrateur 

De la meme maniere que pour les categories et les offres d'emploi, 
l'administrateur dispose d'un panel de gestion des autres administrateurs 
du site. Ce module lui permet ainsi de lister les personnes autorisees a 
gerer l'application, mais egalement de creer de nouveaux comptes ou de 
supprimer des comptes existants. 

Scenario B4 : configurer le site Internet 

Enfin, l'administrateur dispose d'un dernier panneau d'administration 
qui lui permet de gerer l'ensemble des comptes affilies en attente de vali- 
dation. Cet espace lui permet en effet d'activer ou de desactiver a sa 
guise le compte d'un affilie souhaitant profiter de l'API. 

Lorsque le compte d'un nouvel affilie est active, le systeme lui cree et lui 
attribue automatiquement un jeton unique servant d'identifiant sur 
l'API. Ce jeton lui est envoye directement par e-mail pour lui indiquer 
que son compte est valide et en etat de marche immediat. 



En resume 



Dans tout developpement web, il est important de ne pas se precipiter 
sur le codage des le premier jour. La premiere etape doit toujours con- 
sister en un recueil des besoins du commanditaire, puis en l'ecriture des 
specifications fonctionnelles et techniques donnant lieu a l'elaboration 
de maquettes visuelles. C'est exactement ce qu'a voulu montrer ce 
deuxieme chapitre. 

Le prochain chapitre entame plus serieusement le projet en s'interessant a la 
creation de tout le modele de la base de donnees de Jobeet. II y est notam- 
ment question de la prise en main de l'ORM Doctrine, de la generation 
automatique de la base de donnees et des classes de modele, de l'ecriture de 
donnees initiales de test, de la generation d'un premier module fonctionnel, 
et bien sur des premieres lignes de code PHP tant attendues. . . 



chapitre 
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Concevoir 
le modele de donnees 



MOTS-CLES 



La base de donnees est l'un des piliers de toute application web 
mais sa nature et sa structure peuvent rendre difficile 
son integration dans le developpement de l'application. 
Heureusement, Symfony en simplifie la manipulation grace 
a la couche d'ORM embarquee Doctrine, qui automatise 
la creation de la base de donnees a partir d'un schema 
de description et de quelques fichiers de donnees initiales. 



► L'ORM Doctrine 

► Base de donnees 

► Programmation orientee objet 



Parcimonie du code ecrit 



Symfony realise une majeure partie du travail a la 
place du developpeur ; le module web ainsi cree 
sera entierement fonctionnel sans que vous ayez a 
ecrire beaucoup de code PHP. 



Ce troisieme chapitre se consacre principalement a la base de donnees de 
Jobeet. Les notions de modele de donnees, de couche d'abstraction de bases 
de donnees, de librairie d'ORM ou bien encore de generation de code seront 
abordees. Enfin, le tout premier module fonctionnel de l'application sera 
developpe malgre le peu de code que nous aurons a ecrire. 



Installer la base de donnees 

Le framework Symfony supporte toutes les bases de donnees compati- 
bles avec PDO (MySQL, PostgreSQL, SQLite, Oracle, MSSQL...). 
PDO est la couche native d'abstraction de bases de donnees de PHP. 
Dans le cadre de ce projet, c'est MySQL qui a ete choisi. 

Creer la base de donnees MySQL 

La premiere etape consiste bien evidemment a creer une base de donnees 
locale dans laquelle seront sauvegardees et recuperees les donnees de 
Jobeet. Pour ce faire, la commande mysql admin suffit amplement, mais 
un outil graphique comme PHPMyAdmin ou bien MySQL Query Browser fait 
aussi tres bien l'affaire. 

$ mysqladmin -uroot -pmYsEcret create jobeet 

Le parti pris d'utiliser MySQL pour Jobeet tient juste dans le fait que 
c'est le plus connu et le plus accessible pour tous. Un autre moteur de 
base de donnees aurait pu etre choisi a la place dans la mesure ou le code 
SQL sera automatiquement genere par FORM. C'est ce dernier qui se 
preoccupe d'ecrire les bonnes requetes SQL pour le moteur de base de 
donnees installe. 

Configurer la base de donnees pour le projet Symfony 

Maintenant que la base de donnees est creee, il faut specifier a Symfony 
sa configuration afin quelle puisse etre reliee a l'application via FORM. 
La commande configure: database configure Symfony pour fonctionner 
avec la base de donnees : 

$ php symfony configure:database --name=doctri ne 
--dass=sfDoctrineDatabase 

"mysql :host="localhost;dbname=jobeet" root mYsEcret 

Apres avoir configure la connexion a la base de donnees, toutes les con- 
nexions qui referencent Propel dans le fichier config/databases.yml 
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doivent etre supprimees manuellement. Le fichier de configuration de la 
base de donnees doit finalement ressembler a celui-ci : 



all : 

doctrine 
class : 
param: 
dsn : 



sf Doctri neDatabase 



' mysql : host=l ocal host ; dbname=jobeet ' 
username: root 
password: mYsEcret 

La tache configure: database accepte trois arguments : le DSN (Data 
Set Name, lien vers la base de donnees) PDO, le nom d'utilisateur et le 
mot de passe permettant d'acceder a la base de donnees. Si aucun mot de 
passe nest requis pour acceder a la base de donnees du serveur de deve- 
loppement, le troisieme argument peut etre omis. 



Remarque Fichier databases.yml 

La tache configure: database stocke la 
configuration de la base de donnees dans le fichier 
de configuration config/databases .yml . 
Au lieu d'utiliser cette tache, le fichier peut etre 
edite manuellement. 



Presentation de la couche d'ORM Doctrine 

Symfony fournit de base deux bibliotheques d'ORM Open-Source pour 
interagir avec les bases de donnees : Propel et Doctrine, agissant toutes 
deux comme des couches d'abstraction. Cependant, cet ouvrage ne 
s'interesse qua l'utilisation de Symfony avec FORM Doctrine. 



Choix de conception Pourquoi Doctrine plutot que Propel ? 

Le choix de la librairie Doctrine par rapport a Propel s'impose de lui-meme pour plusieurs rai- 
sons. Bien que la librairie Propel soit aujourd'hui mature, il n'en resulte pas moins que son age 
lui fait defaut. En effet, ce projet Open-Source rendit bien des services aux developpeurs 
jusqu'a aujourd'hui, mais malheureusement son support et sa communaute ne sont plus aussi 
actifs qu'auparavant. Propel est clairement sur le point de mourir, laissant place a des outils 
plus recents comme Doctrine. 

La librairie Doctrine dispose de plusieurs atouts par rapport a Propel tels qu'une API simple et 
fluide pour definir des requetes SQL, de meilleures performances avec les requetes complexes, 
la gestion native des migrations, la validation des donnees, I'heritage de tables ou bien encore 
le support de differents comportements utiles (« sluggification », ensembles imbriques, sup- 
pressions virtuelles, recherches...). 

De surcroit, le projet Doctrine jouit aujourd'hui d'une communaute toujours plus active et 
d'une documentation abondante. D'ailleurs, a I'heure ou nous ecrivons ces lignes, un livre 
contenant toute la documentation technique de Doctrine est en preparation. 
Enfin, le projet Doctrine est supporte par Sensio Labs, societe editrice du framework Symfony. 
Le developpeur principal du projet Doctrine, Jonathan Wage, a rejoint I'equipe de production 
de la societe en 2008 pour se consacrer davantage au developpement et a Integration de 
Doctrine dans Symfony. 
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Qu'est-ce qu'une couche d'abstraction de base de donnees ? 



Une couche d'abstraction de bases de donnees est une interface logicielle 
qui permet de rendre independant le systeme de gestion de base de don- 
nees de l'application. Ainsi, une application fonctionnant sur un systeme 
de base de donnees relationnel (SGBDR), comme MySQL, doit pou- 
voir fonctionner de la meme maniere avec un systeme de base de don- 
nees different (Oracle par exemple) sans avoir a modifier son code 
fonctionnel. Une simple ligne de configuration dans un fichier doit suf- 
fire a indiquer que le gestionnaire de base de donnees n'est plus le meme. 

Depuis la version 5.1.0, PHP dispose de sa propre couche d'acces aux 
bases de donnees : PDO. PDO est l'abreviation pour « PHP Data 
Objects ». II s'agit en fait surtout d'une interface commune d'acces aux 
bases de donnees plus qu'une veritable couche d'abstraction. En effet, 
avec PDO, il est necessaire d'ecrire soi-meme les requetes SQL pour 
interroger la base de donnees a laquelle l'application est connectee. Or, 
les requetes sont largement dependantes du systeme de base de donnees, 
bien que SQL soit un langage standard et normalise. Chaque SGBDR 
propose en realite ses propres fonctionnalites, et done sa propre version 
enrichie de SQL pour interroger la base de donnees. 

Doctrine s'appuie sur l'extension PDO pour tout ce qui concerne la con- 
nexion et l'interrogation des bases de donnees (requetes preparees, tran- 
sactions, ensembles de resultats...). En revanche, l'API se charge de 
convertir les requetes SQL pour le systeme de gestion de base de don- 
nees actif, ce qui en fait une veritable couche d'abstraction. 

La librairie Doctrine supporte toutes les bases de donnees compatibles 
avec PDO telles que MySQL, PostgreSQL, SQLite, Oracle, MSSQL, 
Sybase, IBM DB2, IBM Informix. . . 

Qu'est-ce qu'un ORM ? 

ORM est le sigle de « Object- Relational Mapping » ou « Mapping 
Objet Relationnel » en francais. Une couche d'ORM est une interface 
logicielle qui permet de representer et de manipuler sous forme d'objet 
tous les elements qui composent une base de donnees relationnelle. 

Ainsi, une table ou bien un enregistrement de celle-ci est percu comme un 
objet du langage sur lequel il est possible d'appliquer des actions (les 
methodes). Lavantage de cette approche est de s'abstraire completement de 
la technologie de gestion de la base de donnees qui fonctionne en arriere- 
plan, et de ne travailler qu'avec des objets ayant des liaisons entre eux. 

A partir d'un modele de donnees defini plus loin dans ce chapitre, Doc- 
trine construit entierement la base de donnees pour le SGBDR choisi, 



ainsi que les classes permettant d'interroger la base de donnees au travers 
d'objets. Grace aux relations qui lient les tables entre elles, Doctrine est 
par exemple capable de retrouver tous les enregistrements d'une table qui 
dependent d'un autre dans une seconde table. 

Activer I'ORM Doctrine pour Symfony 

Les deux ORMs du framework, Propel et Doctrine, sont tous deux 
fournis nativement sous forme de plug-ins internes. A ce jour, Propel est 
encore la couche d'ORM activee par defaut dans la configuration d'un 
projet Symfony. II faut done commencer par le desactiver, puis activer le 
plug-in sfDoctrinePlugin qui contient toute la bibliotheque Doctrine. 
La manipulation est triviale puisqu'elle ne necessite qu'une unique 
modification dans le fichier de configuration generate du projet config/ 
ProjectConfiguration.class.php comme le montre le code suivant : 

public function setupO 
{ 

$thi s->enab1 ePI ugi ns (array ( ' sf Doctr i nePI ugi n ' )) ; 
$thi s->disab1 ePl ugins(array( ' sf Propel PI ugin ' )) ; 

} 

Le meme resultat peut egalement etre obtenu en une seule ligne de code. 
Le listing ci-dessous active par defaut tous les plug-ins du projet, hormis 
ceux specifies dans le tableau passe en parametre. 

public function setupO 
{ 

$thi s->enab1 eAI 1 PI ugi nsExcept (array ( ' sf Propel PI ugi n ' , 
'sfCompatlOPlugin')) ; 

} 

Lune ou l'autre de ces deux operations necessite de vider le cache du 
projet Symfony. 

j $ php symfony cache: clear 

D'autre part, certains plug-ins comme sfDoctrinePlugin embarquent 
des ressources supplementaires qui doivent etre accessibles depuis un 
navigateur web comme des images, des feuilles de style ou bien encore 
des fichiers JavaScript. Lorsqu'un plug-in est nouvellement installe et 
active, l'execution de la tache pi ugi n : publ i sh-assets cree les liens sym- 
boliques qui permettent de publier toutes les ressources web necessaires. 

$ php symfony pi ugi n : publ i sh-assets 



Comme Propel n'est pas utilise pour ce projet Jobeet, le lien symbolique 
vers le repertoire web/sf Propel PI ugi n qui subsiste peut etre supprime en 
toute securite. 

| $ rm web/sf Propel PI ugi n 

II est temps a present de s'interesser a l'architecture de la base de don- 
nees qui accueille toutes les donnees de Jobeet. 



Concevoir le modele de donnees 

Le chapitre precedent a decrit les cas d'utilisation de l'application Jobeet 
ainsi que tous les composants necessaires : les offres d'emploi, les affilia- 
tions et les categories. Neanmoins, cette definition des besoins fonction- 
nels n'est pas suffisante. Une transposition sous forme d'un diagramme 
UML apporte plus de visibilite sur chaque objet et les relations qui les 
lient les uns aux autres. 



Decouvrir le diagramme UML « entite-relation » 

D'apres l'etude des besoins fonctionnels de Jobeet, on determine claire- 
ment les differentes relations suivantes : 

• une offre d'emploi est associee a une categorie ; 

• une categorie a entre 0 et N offres d'emploi associees ; 

• une affiliation possede entre 1 et N categories ; 

• une categorie a entre 0 et N affiliations. 

II en resulte presque naturellement le modele « entite-relation » suivant. 



Figure 3-1 

Diagramme entite-relation de Jobeet 
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Ce diagramme decrit egalement les differentes proprietes de chaque 
objet qui deviendront les noms des colonnes de chaque table de la base 
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de donnees. Un champ createcLat a ete ajoute a quelques tables. Sym- 
fony reconnait ce type de champ et fixe sa valeur avec la date courante du 
serveur lorsqu'un enregistrement est cree. II en va de meme pour les 
champs updatecLat : leur valeur est definie a partir de la date courante 
du serveur lorsque l'enregistrement est mis a jour dans la table. 

Mise en place du schema de definition de la base 

De I'importance du schema de definition de la base de donnees... 

Les offres d'emploi, les affiliations et les categories doivent etre stockees 
dans la base de donnees relationnelle installee plus haut. Symfony est un 
framework qui a la particularite d'etre entierement oriente Objet, ce qui 
permet au developpeur de manipuler des objets aussi souvent que pos- 
sible. Par exemple, au lieu d'ecrire des requetes SQL pour retrouver des 
enregistrements de la base de donnees, il sera plus naturel et logique de 
manipuler des objets. 

Dans Symfony, les informations de la base de donnees relationnelle sont 
representees (« mappees » en langage informatique) en un modele objet. 
La generation et la gestion de modeles objets sont entierement laissees a 
la charge de l'ORM Doctrine. Pour ce faire, Doctrine a besoin d'une 
description des tables et de leurs relations pour creer toutes les classes 
correspondantes. II existe deux manieres pour etablir ce schema de des- 
cription. La premiere consiste a analyser une base de donnees existante 
par retro-ingenierie (reverse engineering pour les puristes) ou bien en le 
creant manuellement. 

Ecrire le schema de definition de la base de donnees 

Comme la base de donnees hexiste pas encore et que nous souhaitons la 
garder agnostique, le schema de definition de la base de donnees doit etre 
ecrit a la main dans le fichier config/doctrine/schema.yml. Le repertoire 
conf i g/doctri ne/ hexiste pas encore, il doit etre cree a la main. 

$ mkdi r conf i g/doctri ne 

$ touch config/doctrine/schema.yml 

Le fichier config/doctrine/schema.yml contient une definition au 
format YAML de tous les elements qui composent la base de donnees. 
Cette description indique la structure de chaque table et de ses champs 
respectifs, les contraintes appliquees sur chacun d'eux ainsi que toutes les 
relations qui les lient les unes aux autres. Le code suivant correspond au 
schema de definition de la base de donnees de l'application Jobeet. 



Contenu du fichier config/doctrine/schema.yml 



E 



} 



JobeetCategory : 

actAs: { Timestampable: 
col umns : 

name: { type: stri ng(255) , notnull: true, unique: true } 



JobeetJob: 

actAs: { Timestampable: 
col umns : 

category_i d : 

type: 

company: 

logo: 

url : 

position: 
location: 
description: 
how_to_apply 
token : 



{ type: integer, notnull: true } 



type: str 

type: str 

type: str 

type: str 



type: str 
type: str 
type: str 



ng(255) } 

ng(255), notnull: true } 
ng(255) } 
ng(255) } 



type: string(255), notnull: true } 



ng(255), notnull: true } 
ng(4000), notnull: true } 
ng(4000), notnull: true } 
type: string(255), notnull: true, 

unique: true } 
type: boolean, notnull: true, default: 
type: boolean, notnull: true, default: 
type: string(255), notnull: true } 
type: timestamp, notnull: true } 



is_public: 
i s_activated 
emai 1 : 
expi res_at: 
relations: 

JobeetCategory: { local: category_id, foreign: id 
foreignAlias : JobeetJobs } 



1 } 

0 } 



JobeetAffiliate: 

actAs: { Timestampable: 
col umns : 

url : 

emai 1 : 



} 



{ type: string(255), notnull: true } 
{ type: string(255), notnull: true, 

unique: true } 
{ type: string(255), notnull: true } 
{ type: boolean, notnull: true, default: 0 } 



token : 
i s_acti ve 
relations: 

JobeetCategories : 

class: JobeetCategory 

ref CI ass : JobeetCategoryAf f i 1 i ate 

1 ocal : af f i 1 i ate_i d 

foreign: category_id 

foreignAlias: JobeetAff i 1 i ates 

JobeetCategoryAffiliate: 
col umns : 

category_id: { type: integer, primary: true } 
af f i 1 i ate_i d : { type: integer, primary: true } 
relations : 

JobeetCategory: { onDelete: CASCADE, local: category_id, 
foreign: id } 

JobeetAffiliate: { onDelete: CASCADE, local: affiliate_id, 
foreign: id } 
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Le schema est la traduction directe, en format YAML, du diagramme 
« entite-relation ». On identifie ici clairement quatre entites dans ce 
modele: JobeetCategory, JobeetJob, JobeetAff i 1 i ate et 
JobeetCategoryAffiliate. Les relations entre les objets JobeetCategory 
et JobeetJob decouvertes plus haut sont bien retranscrites au meme titre 
que celles entre JobeetCategory et JobeetAffiliate via la quatrieme 
entite JobeetCategoryAf fi 1 i ate. 

De plus, ce modele definit des comportements pour certaines entites 
grace a la section actAs. Les comportements {behaviors en anglais) sont 
des outils internes de Doctrine qui permettent d'automatiser des traite- 
ments sur les donnees lorsqu'elles sont ecrites dans la base. Ici, le com- 
portement Timestampable permet de creer et de fixer les valeurs des 
champs created_at et updatecLat a la volee par Doctrine. 

Si les tables de la base de donnees sont directement creees grace aux 
requetes SQL ou bien a l'aide d'un editeur graphique, le fichier de confi- 
guration schema. yml correspondant peut etre construit en executant la 
tache doctrine:build-schema. 

$ php symfony doctri ne : bui 1 d-schema 



Format YAML pour la serialisation des donnees 

D'apres le site officiel de YAML, YAML est « un standard de serialisation des donnees, facile a 
utiliser pour un etre humain quel que soit le langage de programmation ». 
En d'autres termes, YAML est un langage simple pour decrire des donnees (chaine de carac- 
teres, entiers, dates, tableaux ou tableaux associatifs). 

En YAML, la structure est presentee grace a I'indentation. Les listes d'elements sont identifies 
par un tiret, et les paires cle/valeur d'une section par une virgule. YAML dispose egalementd'une 
syntaxe raccourcie pour decrire la meme structure en moins de lignes. Les tableaux sont explici- 
tement identifies par des crochets [] et les tableaux associatifs avec des accolades {}. 
Si vous n'etes pas familier avec YAML, c'est le moment de commencer a vous y interesser dans la 
mesure ou le framework Symfony I'emploie excessivement pour ses fichiers de configuration. 
II y a enfin une chose importante dont il faut absolument se souvenir lorsque Ton edite un 
fichier YAML : I'indentation doit toujours etre composee d'un ou de plusieurs espaces, mais 
jamais de tabulations. 

Declaration des attributs des colonnes d'une table en format YAML 

Le fichier schema. yml contient la description de toutes les tables et de 
leurs colonnes. Chaque colonne est decrite au moyen des attributs 
suivants : 

1 type: le type de la colonne (float, decimal, string, array, 
object, blob, clob, timestamp, time, date, enum, gzip); 

2 notnull : place a la valeur true, cet attribut rend la colonne 
obligatoire ; 



APROPOS Comportements 
supportes par Doctrine 

L'attribut onDelete determine le comportement 
ON DELETE des cles etrangeres. Doctrine sup- 
ports les comportements CASCADE, SET NULL 
et RESTRICT. Par exemple, lorsqu'un enregistre- 
ment de la table job est supprime, tous les enre- 
gistrements associes a la table 
jobeet_category_aff i 1 i ate seront 
automatiquement effaces de la base de donnees. 



3 unique : place a la valeur true, l'attribut unique cree automatique- 
ment un index d'unicite sur la colonne. 

La base de donnees existe et est configured pour fonctionner avec Sym- 
fony, et le schema de description de cette derniere est desormais ecrit. 
Neanmoins, la base de donnees est toujours vierge et rien ne permet 
pour le moment de la manipuler. La partie suivante couvre ces proble- 
matiques en presentant comment l'ORM Doctrine genere tout le neces- 
saire pour rendre la base de donnees operationnelle. 

Generer la base de donnees et les classes 
du modele avec Doctrine 

Grace a la description de la base de donnees presente dans le fichier 
config/doctrine/schema.yml, Doctrine est capable de generer les ordres 
SQL necessaires pour creer les tables de la base de donnees ainsi que toutes 
les classes PHP qui permettent de l'attaquer au travers d'objets metiers. 

Construire la base de donnees automatiquement 

La construction de la base de donnees est realisee en trois temps : la 
generation des classes du modele de donnees, puis la generation du 
fichier contenant toutes les requetes SQL a executer, et enfin l'execution 
de ce dernier pour creer physiquement toutes les tables. 

La premiere etape consiste tout d'abord a generer le modele de donnees, 
autrement dit les classes PHP relatives a chaque table et enregistrement 
de la base de donnees. 

| $ php symfony doctrine: build-model 

Cette commande genere un ensemble de fichiers PHP dans le repertoire 
"lib/model/doctrine qui correspondent a une entite du schema de defi- 
nition de la base de donnees. 

Lorsque toutes les classes du modele de donnees sont pretes, 1' etape sui- 
vante doit permettre de generer tous les scripts SQL qui creent physi- 
quement les tables dans la base de donnees. Cette fois encore, Symfony 
facilite grandement le travail du developpeur grace a la tache automa- 
tique doctrine :bui1d-sql qu'il suffit d'executer. 

$ php symfony doctrine :bui1d-sql 
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La tache doctrine :build-sql cree les requetes SQL dans le repertoire 
data/sql/, optimisees pour le moteur de base de donnees configure : 

Echantillon de code du fichier data/sql/schema.sql 

CREATE TABLE jobeet_category (id BICINT AUTO_INCREMENT , name VARCHAR(255) 
NOT NULL COMMENT 'test', created_at DATETIME, updated_at DATETIME, slug 
VARCHAR(255) , UNIQUE INDEX si uggabl e_i dx (slug), PRIMARY KEY(id)) 
ENGINE = INNODB; 



Enfin, il ne reste plus que la derniere etape a franchir. II s'agit de creer 
physiquement toutes les tables dans la base de donnees. Une fois de plus, 
c'est un jeu d'enfant grace aux taches automatiques fournies par le fra- 
mework. Le plug-in sfDoctrinePlugin comporte une tache 
doctrine:insert-sql qui se charge d'executer le script SQL genere pre- 
cedemment pour monter toute la base de donnees. 

| $ php symfony doctri ne : i nsert-sql 

Ca y est, la base de donnees est prete a accueillir des informations. 
Toutes les tables ont ete creees ainsi que les contraintes d'integrite refe- 
rentielle qui lient les enregistrements des tables entre eux. II est desor- 
mais temps de s'interesser aux classes du modele qui ont ete generees. 



A PROPOS Aide sur les taches automatiques 

Comme n'importe quel outil en ligne de commande, 
les taches automatiques de Symfony peuvent 
prendre des arguments et des options. Chaque 
tache est livree avec un manuel d'utilisation qui 
peut etre affiche grace a la commande hel p . 
$ php symfony help 

doctrine:insert-sql 
Le message d'aide liste tous les arguments et 
options possibles, donne la valeur par defaut de 
chacun d'eux, et donne quelques exemples prati- 
ques d'utilisation. 



Decouvrir les classes du modele de donnees 

A la premiere etape de construction de la base de donnees, les fichiers 
PHP du modele de donnees ont ete generes a l'aide de la tache 
doctrine: build-model. Ces fichiers correspondent aux classes PHP qui 
transforment les enregistrements d'une table en objets metiers pour 
Implication. 

La tache doctrine: build-model construit les fichiers PHP dans le reper- 
toire lib/model /doctrine/ qui permettent d'interagir avec la base de 
donnees. En parcourant ces derniers, il est important de remarquer que 
Doctrine genere trois classes par table. Par exemple, pour la table 
jobeet_job : 

1 JobeetJob : un objet de cette classe represente un seul enregistrement 
de la table jobeet_job. La classe est vide par defaut ; 

2 BaseJobeetJob : c'est la superclasse de JobeetJob. Chaque fois que 
Ton execute la tache doctrine: build-model, cette classe est rege- 
neree, c'est pourquoi toutes les personnalisations doivent etre ecrites 
dans la classe Jobeetlob ; 

3 DobeetJobTable : la classe definit des methodes qui retournent prin- 
cipalement des collections d'objets JobeetJob. Cette classe est vide 
par defaut. 
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Les valeurs des colonnes d'un enregistrement sont manipulees a partir 
d'un objet modele en utilisant quelques accesseurs (methodes get*()) et 
mutateurs (methodes set*()) : 

$job = new JobeetJobO ; 
$job->setPosition('Web developer') ; 
$job->save() ; 

echo $job->getPosition() ; 

$job->delete() ; 

Au vu de cette syntaxe, il est evident que manipuler des objets plutot que des 
requetes SQL devient a la fois plus naturel, plus aise mais aussi plus securise, 
puisque l'echappement des donnees est laisse a la charge de l'ORM. 

Le modele de donnees de Jobeet etablit une relation entre les offres d'emploi 
et les categories. Au moment de generer les classes du modele de donnees, 
Doctrine a devine les relations possibles entre les entites et les a reportees 
fidelement dans les classes PHP generees. Ainsi, un objet DobeetJob dis- 
pose de methodes pour definir ou bien recuperer l'objet JobeetCategory qui 
lui est associe comme le presente l'exemple de code ci-dessous. 

Scategory = new JobeetCategoryO ; 
$category->setName( ' Programmi ng ' ) ; 

$job = new JobeetDobO; 
$job->setCategory($category) ; 

Doctrine fonctionne bilateralement, c'est-a-dire que les liaisons entre les 
objets sont gerees aussi bien d'un cote que d'un autre. La classe 
JobeetJob possede des methodes pour agir sur l'objet JobeetCategory 
qui lui est associe mais la classe JobeetCategory possede elle aussi des 
methodes pour definir les objets DobeetJob qui lui appartiennent. 

Generer la base de donnees et le modele en une seule passe 

La tache doctrine: build-all est un raccourci pour les taches executees 
dans cette section et bien d'autres. II est temps maintenant de generer les 
formulaires et les validateurs pour les classes de modele de Jobeet. 

$ php symfony doctrine:build-all --no-confirmation 

Les validateurs seront presentes a la fin de ce chapitre, tandis que les for- 
mulaires seront expliques en detail au cours du chapitre 10. 

Symfony charge automatiquement les classes PHP a la place du deve- 
loppeur, ce qui signifie que nul appel a requi re n'est requis dans le code. 



C'est l'une des innombrables fonctionnalites que le framework automa- 
tise, bien que cela entraine un leger inconvenient. En effet, chaque fois 
qu'une nouvelle classe est ajoutee au projet, le cache de Symfony doit 
etre vide. La tache doctrine: build-model agenereun certain nombre de 
nouvelles classes, c'est pourquoi le cache doit etre reinitialise. 

J $ php symfony cache: clear 

Le developpement d'un projet est fortement accelere grace aux nom- 
breux composants et taches automatiques que fournit nativement le fra- 
mework Symfony. Dans le cas present, la base de donnees ainsi que 
toutes les classes PHP du modele de donnees ont ete mises en place en 
un temps record. Imaginez le temps qu'il vous aurait fallu pour realiser 
tout cela a la main en partant de rien ! 

Toutefois, il manque encore quelque chose d'essentiel pour pouvoir se 
lancer pleinement dans le code et le developpement des fonctionnalites 
de Jobeet. II s'agit bien sur des donnees initiales qui permettent a 1' appli- 
cation de s'initialiser et d'etre testee. La section suivante se consacre 
pleinement a ce sujet. 



ASTUCE Comprendre la syntaxe des taches 
automatiques de Symfony 

Une tache Symfony est constitute d'un espace de 
nom (namespace pour les puristes) et d'un nom. 
Chacun d'eux peut etre raccourci tant qu'il n'y a 
pas d'ambigui'te avec d'autres taches. Ainsi, les 
commandes suivantes sont equivalentes a 
cache:clear : 
$ php symfony cache :cl 
$ php symfony ca:c 

Comme la tache cache: clear est frequem- 
ment utilisee, elle possede une autre abreviation 
encore plus courte : 
$ php symfony cc 



Preparer les donnees initiales de Jobeet 

Les tables ont ete creees dans la base de donnees mais celles-ci sont tou- 
jours vides. II faut done preparer quelques jeux de donnees pour remplir 
les tables de la base de donnees au fur et a mesure de l'avancee du projet. 

Decouvrir les differents types de donnees 
d'un projet Symfony 

Pour n'importe quelle application, il existe trois types de donnees : 

1 les donnees initiales : ce sont les donnees dont a besoin l'application 
pour fonctionner. Par exemple, Jobeet requiert quelques categories. 
S'il n'y en a pas, personne ne pourra soumettre d'offre d'emploi. Un 
utilisateur administrateur capable de s'authentifier a l'interface 
d'administration (backend en anglais) est egalement necessaire ; 

2 les donnees de test : les donnees de test sont necessaires pour tester 
l'application et pour s'assurer quelle se comporte comme les cas d'utili- 
sation fonctionnels le specifient. Bien evidemment, le meilleur moyen 
de le verifier est d'ecrire des series de tests automatises ; c'est pourquoi 
des tests unitaires et fonctionnels seront developpes pour Jobeet. Ainsi, 
a chaque fois que les tests seront executes, une base de donnees saine 
constitute de donnees fraiches et pretes a etre testees sera necessaire ; 
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3 les donnees utilisateur : les donnees utilisateur sont creees par les utili- 
sateurs au cours du cycle de vie normal de l'application. 

Pour le moment, Jobeet requiert quelques donnees initiales pour initia- 
liser l'application. Symfony fournit un moyen simple et efficace de 
definir ce type de donnees a l'aide de fichiers YAML, comme l'explique 
la partie suivante. 

Definir des jeux de donnees initiales pour Jobeet 

Chaque fois que Symfony cree les tables dans la base de donnees, toutes 
les donnees sont perdues. Pour peupler la base de donnees avec des don- 
nees initiales, nous pourrions creer un script PHP, ou bien executer 
quelques requetes SQL avec le programme MySQL. Neanmoins, 
comme ce besoin est relativement frequent, il existe une meilleure facon 
de proceder avec Symfony. II s'agit de creer des fichiers YAML dans le 
repertoire data/fixtures/, puis d'executer la tache doctrine: data-load 
pour les charger en base de donnees. 

Les deux listings suivants de code YAML definissent un jeu de donnees 
initiales pour l'application. Le premier fichier declare les donnees pour 
remplir la table jobeet_category tandis que le second sert a peupler la 
table des offres d'emploi jobeet_job. 

Contenu du fichier data/fixtures/categories.yml 

JobeetCategory : 
design : 

name: Design 
programmi ng : 

name: Programming 
manager: 

name: Manager 
admi ni strator : 

name: Administrator 

Contenu du fichier data/fixtures/jobs.yml 

Jobeet Job : 

job_sensio_labs: 

JobeetCategory: programming 



type: full -time 

company: Sensio Labs 

logo: sensio-labs.gif 

url : http://www.sensiolabs.com/ 

position: Web Developer 

location: Paris, France 



description: | 

You've already developed websites with Symfony and you 
want to work with Open-Source technologies. You have a 



minimum of 3 years experience in web development with PHP 
or Java and you wish to participate to development of 
Web 2.0 sites using the best frameworks available. 

how_to_apply : | 

Send your resume to fabien.potencier [at] sensio.com 

is_public: true 

is_activated: true 

token: job_sensio_labs 

emai 1 : j ob@exampl e . com 

expires_at: '2010-10-10' 

job_extreme_sensio: 

JobeetCategory : design 



part-time 
Extreme Sensio 
extreme-sensio . gi f 
http://www.extreme-sensio.com/ 
Web Designer 
Paris, France 



type: 
company: 
logo: 
url : 

position: 
location : 
description: | 

Lorem ipsum dolor sit amet, consectetur adipisicing elit, 
sed do eiusmod tempor incididunt ut labore et dolore magna 
aliqua. Ut enim ad minim veniam, quis nostrud exercitation 
ullamco laboris nisi ut aliquip ex ea commodo consequat. 
Duis aute irure dolor in reprehenderit in. 

Voluptate velit esse cillum dolore eu fugiat nulla 
pariatur. Excepteur sint occaecat cupidatat non proident, 
sunt in culpa qui officia deserunt mollit anim id est 
laborum. 
how_to_apply : | 

Send your resume to fabien.potencier [at] sensio.com 
is_public: true 
is_activated: true 
token: job_extreme_sensio 
emai 1 : j ob@exampl e . com 

expires_at: '2010-10-10' 

Un fichier de donnees est ecrit au format YAML, et decrit les objets 
modeles references par un nom unique. Par exemple, les deux offres 
d'emploi sont intitulees job_sensio_labs et job_extreme_sensio. Cet 
intitule sert a lier les objets entre eux sans avoir a exprimer explicitement 
les cles primaires, qui sont dans la plupart des cas auto-incrementees et 
qui varient perpetuellement. La categorie de l'offre d'emploi 
job_sensio_labs est programming, ce qui correspond a la categorie 
nommee « Programming ». 

Dans un fichier YAML, lorsqu'une chaine de caracteres contient des 
retours a la ligne (comme la colonne description dans les donnees ini- 
tiates du fichier d'offres d'emploi), la barre verticale (pipe en anglais) | 
sert a indiquer que la chaine occupera plusieurs lignes. 



Remarque Telecharger les images relatives 
aux donnees initiates 

Le fichier de donnees initiales des offres reference 
deux images. Vous pouvez les telecharger : 

► http://www.symfony-project.org/get/ 
jobeet/sensio-labs.gif 

► http://www.symfony-project.org/get/ 
jobeet/extreme-sensio.gif 

Vous devrez ensuite les placer dans le repertoire 
uploads/jobs/. 
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ASTUCE Propel versus Doctrine 

Propel a besoin que les fichiers de donnees de 
test soient prefixes par des nombres pour deter- 
miner dans quel ordre les fichiers doivent etre 
charges. Avec Doctrine, ce n'est pas necessaire 
puisque toutes les donnees sont chargees et sau- 
vegardees dans le bon ordre pour s'assurer que 
les des etrangeres sont definies correctement. 



Bien qu'un fichier de donnees contienne des objets provenant d'un ou de 
plusieurs modeles, il est vivement recommande de ne creer qu'un seul 
fichier par modele. 

Dans un fichier de donnees, il n'est nul besoin de definir toutes les 
valeurs des colonnes. Si certaines valeurs ne sont pas definies, Symfony 
utilisera la valeur par defaut definie dans le schema de la base de don- 
nees. Comme Symfony utilise Doctrine pour charger les donnees en 
base de donnees, tous les comportements natifs (comme la fixation auto- 
matique des colonnes created_at et updated_at) et les comportements 
personnalises ajoutes aux classes de modele sont actives. 

Charger les jeux de donnees de tests en base de donnees 

Une fois les fichiers de donnees initiales crees, leur chargement en base 
de donnees est aussi simple que de lancer une tache automatique. Le 
plug-in sfDoctrinePlugin possede la commande doctrine: data-load 
qui se charge d'enregistrer toutes ces donnees dans la base de donnees. 

$ php symfony doctrine: data-load 

Executer l'une apres l'autre toutes les taches pour regenerer la base de 
donnees, construire les classes du modele et inserer les donnees initiales 
peut se reveler tres vite fastidieux. Symfony propose une tache simple 
qui realise toutes ces operations en une seule passe comme l'explique la 
section suivante. 

Regenerer la base de donnees et le modele en une seule 
passe 

La tache doctrine: build-all -reload est un raccourci pour la tache 
doctrine:build-all suivi de la tache doctrine:data-load. Celle-ci 
s'occupe de regenerer toute la base de donnees et les classes du modele, 
puis finit par charger les donnees initiales dans les tables. 

j $ php symfony doctrine:build-all-reload 

II suffit de lancer la commande doctrine:build-all-reload puis de 
s'assurer que tout a bien ete genere depuis le schema. Cette tache genere les 
classes de formulaires, de filtres, de modele, supprime la base de donnees 
existante et la recree avec toutes les tables peuplees par les donnees initiales. 
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Profiter de toute la puissance de Symfony 
dans le navigateur 

L'interface en ligne de commande est plutot pratique mais n'est malgre 
tout pas tres attrayante, qui plus est pour un projet web. A ce stade 
d'avancement du projet, Jobeet est deja pret a accueillir les pages web 
dynamiques qui interagissent avec la base de donnees. 

La suite du chapitre aborde les fonctionnalites essentielles d'affichage de 
la liste des offres d'emploi, et d'edition et de suppression d'une offre 
existante. Comme cela a deja ete explique au premier chapitre, un projet 
Symfony est constitue &' applications. Chaque application est ensuite 
divisee en modules. 

Un module est un ensemble autonome de code PHP qui represente une 
fonctionnalite de l'application (le module API par exemple), ou bien un 
ensemble de manipulations que l'utilisateur peut realiser sur un objet du 
modele (un module d'offres d'emploi par exemple). 

Generer le premier module fonctionnel « job » 

Le module principal de l'application Jobeet est bien evidemment celui 
qui permet de creer et de consulter des offres. Le framework Symfony 
est capable de generer automatiquement un module fonctionnel complet 
pour un modele donne. Ce module integre de base toutes les fonction- 
nalites de manipulation simples telles que l'ajout, la modification, la sup- 
pression et la consultation. 

Ce travail est realise a l'aide de la commande doctrine : generate-modul e 
comme le presente le code ci-dessous. 

$ php symfony doctri ne : generate-modul e --with-show 
--non-verbose-templates frontend job JobeetJob 

La tache doctrine:generate-module genere un module job dans l'appli- 
cation frontend pour le modele JobeetJob. Comme avec la plupart des 
taches Symfony, quelques fichiers et repertoires ont ete crees. Tous les 
fichiers du present module ont ete fabriques sous le repertoire apps/ 
f rontend/modul es/job/. 

Composition de base d'un module genere par Symfony 

Le tableau ci-apres decrit les repertoires de base qui ont ete generes par 
Symfony a 1' execution de la tache doctrine: generate-modul e dans le 
repertoire apps/f rontend/modul es/job/. 



Tableau 3-1 Repertoires du module apps/frontend/modules/job 



Repertoire 


Description 


actions/ 


Les actions du module 


tempi ates/ 


Les templates du module 



Le repertoire actions/ contient la classe dans laquelle se trouvent toutes 
les actions CRUD {create, retrieve, update et delete) de base qui permet- 
tent de manipuler une offre d'emploi. A toutes ces actions est associe un 
ensemble de fichiers de templates generes dans le repertoire templates/. 

Decouvrir les actions du module « job » 

Le fichier actions/actions.class.php definit toutes les actions possibles 
pour le module job. C'est exactement ce que decrit le tableau 3-2. 

Edit Job 



Figure 3-2 

Formulaire d'edition d'une offre d'emploi 



Category id 

Type 
Company 
Logo 
Url 
Position 
Location 



full-time 



Sensio Labs 



sensiojabs.png 



http://www.sensiolabs.com 



Web Developer 



Paris. France 



You've already developed 
websites with symfony and you \±) 
Description [want to work 

with Open-Source 
technologies. You have a 



How to apply 



Send your resume to 
£ abien . potencier [at] 
sensio.com 



Token job_sensio_labs 

Is public h>l 

Is activated M 

Email job@example.com 

Expires at ( to 10 ^ 2010 ( 00 00 ^ 

Created at ( 01 13 2009 nfrj ( 09 07 

Updated at ( 01 13 ^ 2009 ^ ( 09 ^ : ( 07 ^ 

Cancel Delete Save 
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Tableau 3-2 Liste des actions du fichier 
apps/frontend/modules/job/actions/actions.class.php 



i ndex 


Affiche les enregistrements d'une table 


show 


Affiche les champs et les valeurs d'un enregistrement donne 


new 


Affiche un formulaire pour creer un nouvel enregistrement 


create 


Cree un nouvel enregistrement 


edit 


Affiche un formulaire pour editer un enregistrement existant 


update 


Met a jour les informations d'un enregistrement d'apres les valeurs 
transmises par I'utilisateur 


delete 


Supprime un enregistrement donne de la table 



Le module job est desormais accessible et utilisable depuis un navigateur 
web a l'adresse suivante : 
► http://jobeetlocalhost/frontend_dev.php/job 



Comprendre I'importance de la methode magique 
toString() 

Si Ton tente d'editer une offre d'emploi, on remarque que la liste derou- 
lante « Category id » est une selection de l'ensemble des categories pre- 
sentes dans la base de donnees. La valeur de chaque option est obtenue 
grace a la methode toStringO. 

Doctrine essaye d'appeler nativement une methode toStringO en 

devinant un nom de colonne descriptif tel que title, name, subject, etc. 
Si Ton desire quelque chose de plus personnalise, il est alors necessaire 

de redefinir la methode toStringO comme le presente le listing ci- 

apres. Le modele JobeetCategory est capable de deviner la methode 
toStringO en utilisantla colonne name de la table jobeet_category. 

Listing du fichier lib/model/doctrine/JobeetJob.class.php 

class JobeetJob extends BaseJobeetJob 
{ 

public function toStringO 

{ 

return sprintf('%s at %s (%s) ' , $this->getPosition() , 
$this->getCompany() , $this->getLocation()) ; 

} 

} 



Listing du fichier lib/model/doctrine/JobeetAffiliate.class.php 



class JobeetAffiliate extends BaseJobeetAff i 1 i ate 
{ 

public function toStringO 

{ 

return $this->getUr1 () ; 

} 

} 



Ajouter et editer les offres d'emploi 

Les offres d'emploi sont a present pretes a etre ajoutees et editees. Si un 
champ obligatoire est laisse vide ou bien si sa valeur est incorrecte (une 
date invalide par exemple), le processus de validation du formulaire pro- 
voquera une erreur, empechant alors la mise a jour de l'enregistrement. 
Symfony cree effectivement les regies de validation basiques en intros- 
pectant le schema de la base de donnees. 



Token 

Is public 
Is activated 

Email 



Required. 



Required. 



Figure 3-3 

Controle de saisie basique dans le formulaire 
de creation d'une offre d'emploi. 



Expires at 
Created at 

TTn/latori at 



• Required. 
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En resume 



C'est tout pour ce troisieme chapitre. L'introduction etait tres claire. En 
effet, peu de code PHP a ete ecrit mais Jobeet dispose deja d'un module 
d'offres d'emploi entierement fonctionnel et pret a etre ameliore et per- 
sonnalise. Souvenez-vous, moins de code PHP signifie aussi moins de 
risques d'y trouver un bug ! 

Un moyen simple de progresser avant de passer au chapitre suivant est 
de prendre la peine de lire le code genere pour le module et le modele, et 
essayer d'en comprendre le fonctionnement. 

Le chapitre qui suit aborde Fun des plus importants paradigmes utilises 
dans les frameworks web : le patron de conception MVC. 

Le code complet du chapitre est disponible dans le depot SVN de Jobeet 
au tag release_day_03 : 

$ svn co http://svn.jobeet.org/doctrine/tags/re1ease_day_03/ 
jobeet/ 



chapitre 





request 

HTTP. CU. «c. 



demand 




Controller 



data 




response 

HTML. RSS. XML 
J SON, etc 



View 

Templates, layout 



Le controleur 
et la vue 



Structurer une application web n'est pas toujours evident 
du fait des nombreux composants qui interviennent au cours 
du developpement. Le paradigme modele, vue, controleur 
est l'une des solutions capables de repondre a ce besoin. 
Nous verrons ainsi comment Symfony integre parfaitement 
ce motif de conception eprouve dans un projet. 



Le chapitre precedent a montre comment Symfony simplifie la gestion 
d'une base de donnees en abstrayant les differences entre les moteurs de 
base de donnees et en convertissant des objets relationnels en classes 
PHP. De plus, ce fut l'occasion de decouvrir la couche d'ORM Doctrine 
qui permet d'automatiser la creation d'une base de donnees a partir d'un 
schema de description et de quelques fichiers de donnees initiales. 

Ce chapitre s'interesse a la personnalisation du module basique d'offres 
d'emploi genere precedemment. Ce module dispose deja de tout le code 
necessaire pour 1' application : 

• une page qui liste toutes les offres d'emploi ; 

• une page pour creer une nouvelle offre d'emploi ; 

• une page pour mettre a jour une offre d'emploi existante ; 

• une page pour supprimer une offre d'emploi. 

[.'architecture MVC et son implementation 
dans Symfony 

Developper un site en PHP sans recourir a un framework signifie en 
general de n' avoir qu'un seul fichier PHP par page HTML, chaque fichier 
ayant la meme structure : initialisation et configuration generale, logique 
metier relative a la page appelee, recuperation des enregistrements de la 
base de donnees, et enfin le code HTML qui construit la page. 

Meme en utilisant un moteur de templates pour separer la logique 
metier du code HTML final, ou en recourant a une couche d'abstraction 
pour separer les interactions du modele de la base de donnees, il n'en 
resulte pas moins, la plupart du temps, une trop grosse quantite de code 
qui se revele etre un veritable cauchemar a maintenir. 

Heureusement, a chaque probleme sa solution. En developpement web, 
la solution actuelle la plus repandue pour organiser du code de maniere 
efficace et maintenable est d'avoir recours au motif de conception MVC. 
Ce dernier definit en effet un moyen d'organiser le code en fonction de 
la nature de chacune de ses parties. Ce patron separe ainsi le code en 
trois couches distinctes : 

• le modele qui definit la logique metier (la base de donnees appartient 
au modele). Dans Symfony, toutes les classes et tous les fichiers pro- 
pres au modele sont stockes dans le repertoire lib/model / ; 

• la vue qui est l'interface avec quoi l'utilisateur interagit (un moteur de 
templates fait partie de la vue). Dans Symfony, la couche vue est 
principalement constitute de templates PHP. lis sont stockes dans les 
differents repertoires templates/ ; 



• le controleur qui est la partie du code appelant le modele pour en 
recuperer des donnees qu'il transmet ensuite a la vue pour le rendu 
final au client. Lors de Installation de Symfony le premier jour, il a 
ete montre que toutes les requetes etaient gerees par les front control- 
lers (index. php et f rontend_dev. php). Ces controleurs frontaux dele- 
guent le veritable travail aux actions. Ces dernieres sont logiquement 
groupees a l'interieur de modules. 




demand 




Controller 



data 



response 

HTML RSS, XML 
J SON, etc 



View 

Templates, layoui 



Figure 4-1 

Schema de fonctionnement du motif de conception MVC 



Les prochaines pages de cet ouvrage s'appuient sur les maquettes {mock- 
ups en anglais) etablies au second chapitre. La page d'accueil et la page 
des offres seront personnalisees et dynamisees. Dans la foulee, de nom- 
breuses ameliorations seront apportees dans differents fichiers, afin de 
presenter la structure de fichiers de Symfony et la maniere de separer le 
code entre les differentes couches. 



Habiller le contenu de chaque page avec un 
meme gabarit 



Decorer une page avec un en-tete et un pied de page 

Pour commencer, en regardant de plus pres les maquettes, on identifie 
clairement que la plupart des pages HTML se ressemblent. Or, il a ete 
demontre juste avant qu'il vaut mieux eviter a tout prix la duplication de 
code, qu'il s'agisse de code HTML ou bien de code PHP. Mais com- 
ment empecher cette copie des elements communs de la vue ? Un moyen 



Bonnes pratiques Le principe « DRY » 

DRY est un acronyme pour Don't Repeat 
Yourself. II s'agit d'une philosophie en deve- 
loppement informatique qui consiste a limiter le 
code redondant (i.e. la duplication). De cette 
maniere, le debogage et la maintenance s'en 
voient grandement simplifies. 
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simple de resoudre ce probleme est de definir un en-tete et un pied de 
page, puis de les inclure dans chaque template. 



Figure 4-2 

Structure d'une page web 
en trois parties 



template 



template 



Decorer le contenu d'une page avec un decorateur 

Malheureusement, ici, l'en-tete et le pied de page ne contiennent pas de 
code HTML valide. II faut done opter pour une meilleure maniere de 
faire. Au lieu de reinventer la roue, Symfony s'appuie sur un autre motif 
de conception : le patron Decorateur {decorator en anglais). Ce dernier 
resout le probleme autrement, en habillant le contenu rendu par le tem- 
plate principal, appele layout. 



layout 
template 



layout 



Figure 4-3 

Schema de fonctionnement 
du motif de conception Decorateur 



Dans Symfony, le layout par defaut d'une application est un fichier PHP 
appele layout. php et se trouve dans le repertoire apps/f rontend/ 
templates/. Celui-ci contient l'ensemble des templates globaux d'une 
application. 

Listing du fichier apps/frontend/templates/layout.php 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transi ti onal //EN" 
"http://www.w3 . org/TR/xhtml 1/DTD/xhtml 1-transitional .dtd"> 
<html xmlns="http://www. w3.org/1999/xhtml" xml : 1 ang="en" lang="en"> 
<head> 

<ti tl e>Jobeet - Your best job board</ti tl e> 
<link rel="shortcut icon" href="/favi con . i co" /> 
<?php include javascriptsO ?> 
<?php include stylesheets () ?> 

</head> 
<body> 

<div id="container"> 
<div id="header"> 

<div class="content"> 
<hlxa href="/job"> 

<img src="/images/jobeet.gif" alt="Jobeet Dob Board" /> 
</ax/hl> 
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<div id="sub_header"> 
<div cl ass="post"> 

<h2>Ask for people</h2> 
<di v> 

<a href="/job/new">Post a Job</a> 
</di v> 
</di v> 

<div cl ass="search"> 
<h2>Ask for a job</h2> 
<form action="" method="get"> 

<input type="text" name="keywords" 

id="search_keywords" /> 
<input type=" submit" val ue="search" /> 
<div class="help"> 

Enter some keywords (city, country, position, 
</di v> 
</form> 
</di v> 
</di v> 
</di v> 
</di v> 

<div id="content"> 

<?php if ($sf user->hasFlash(' notice' )) : ?> 
<div cl ass="f 1 ash_noti ce"> 

<?php echo $sf user->getF1ash('notice') ?> 
</di v> 
<?php endif; ?> 

<?php if ($sf user->hasFlash(' error ')) : ?> 

<div cl ass="f 1 ash_error"> 

<?php echo $sfuser->getF1ash(' error') ?> 
</di v> 
<?php endif; ?> 

<div class="content"> 

<?php echo $sf content ?> 

</di v> 
</di v> 

<div id="footer"> 

<div class="content"> 
<span class="symfony"> 

<img src="/images/jobeet-mini .png" /> 
powered by <a href="http://www. symfony-project.org/" 
<img src="/images/symfony.gif" alt="symfony framework 
</a> 
</span> 
<ul> 

<lixa href="">About ]obeet</ax/l i> 
<li class="feed"xa href="">Full feed</ax/li> 
<lixa href="">]obeet API</ax/li> 
<li class="last"xa href="">Affiliates</ax/li> 
</ul> 



</di v> 
</di v> 
</di v> 
</body> 
; </html> 

Ce layout fait appel a des fonctions et fait reference a des variables PHP. 
La variable $sf_content est l'une des plus importantes car elle est auto- 
matiquement definie par le framework lui-meme et contient le code 
HTML genere par Faction. 

Desormais, en parcourant le module job (http://jobeet.localhost/ 
frontend_dev.php/job), toutes les actions sont decorees par le layout. 



Integrer la charte graphique de Jobeet 



Definition Helpers dans Symfony 

Un helper est une fonction definie par Symfony qui 
peut prendre des parametres et qui renvoie du 
code HTML. La plupart du temps, les helpers 
embarquent des petits bouts de code frequem- 
ment utilises dans les templates et font ainsi 
gagner du temps. 



Recuperer les images et les feuilles de style 

Ce livre ne s'interesse pas au design web, c'est pourquoi toutes les res- 
sources necessaires au projet ont ete preparees a l'avance. Les images et 
les feuilles de style sont toutes disponibles en telechargement. 

1 Telechargez 1' archive des images (http://www.symfony-project.org/get/ 
jobeet/images.zip) et placez les dans le repertoire web/images/ ; 

2 Telechargez l'archive des feuilles de style (http://www.symfony- 
project.org/get/jobeet/css.zip), puis placez les dans le repertoire web/css/. 

Le fichier layout. php fait appel a un « favicon ». Le favicon de Jobeet 
peut etre telecharge a l'adresse http://www.symfony-project.org/get/jobeet/ 
favicon. ico puis depose a la racine du repertoire web/. 

Par defaut, la tache generate: project cree trois repertoires pour les res- 
sources du projet: web/images/ pour les images, web/css/ pour les 
feuilles de style, et web/js/ pour les JavaScripts. C'est l'une des conven- 
tions definies par Symfony, mais il est bien sur possible de les stocker 
ailleurs dans le repertoire web/. 

Le lecteur assidu aura remarque que meme si le fichier main. ess est 
mentionne nulle part dans le layout par defaut, il est finalement present 
dans le code HTML genere. Comment est-ce possible ? 

La feuille de style a ete incluse par 1' appel de la fonction 
inc~lude_stylesheetsO, se trouvant dans le tag <head> du layout. La 
fonction i ncl ude_sty1 esheets () est en fait un helper. 
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Joteet 




■■^.li'jifilLiliM 



Enter some keywords (city, country, position, ...) 



[ NEW JOB 


Category id 


Administrator J 1 




Type 






Company 






Logo 






Url 






Position 






Location 






Description 






How to apply 






Token 






Is public 


i 





Is activated Q 

Email | | 

Expires at ( W\ j*M J [ Wfr 

Created at ( W [ m - 

Figure 4-4 Interface graphique de Jobeet 

Configurer la vue a partir d'un fichier de configuration 

Comment le helper a-t-il connaissance des feuilles de style a inclure 
dans la page ? 

La couche Vue peut etre modelee en editant le fichier de configuration 
de l'application view.yml. Ci-dessous, le contenu de celui genere par 
defaut par la tache gene rate :app : 

Fichier de configuration de la vue, genere par defaut : apps/frontend/config/view.yml 

default: 
http_metas : 

content-type: text/html 
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metas: 
#title: 
#description: 
#keywords : 
#language: 
#robots : 



symfony project 
symfony project 
symfony, project 
en 

index, follow 



stylesheets: 



[main. ess] 



javascripts: 



[] 



has_l ayout: 
1 ayout : 



true 
layout 



Le fichier vi ew . yml configure les parametres par defaut de tous les tem- 
plates de Implication. Par exemple, la section des feuilles de style definit 
un tableau de fichiers de feuilles de style a inclure pour chaque page de 
l'application. Dans le layout, l'inclusion se fait au moyen du helper 
i ncl ude_styl esheets (). 

Dans le fichier de configuration view. yml, la feuille de style referencee par 
defaut est main. ess, et non /ess/main. ess. En fait, les deux definitions 
sont equivalentes puisque Symfony prefixe les chemins relatifs par /ess/. 

Si plusieurs fichiers sont definis, le framework les inclura tous dans 
l'ordre de leur declaration : 

| stylesheets: [main. ess, jobs. ess, job. ess] 

L'attribut media est aussi modifiable et le suffixe .ess peut etre omis. 

stylesheets: [main. ess, jobs. ess, job. ess, print: { media: 
print }] 

Cette configuration genere le code HTML suivant : 

<link rel="styl esheet" type="text/css" medi a="screen" 

href="/css/mai n . ess" /> 
<link rel="stylesheet" type="text/css" medi a="screen" 

href="/css/jobs.css" /> 
<link rel="stylesheet" type="text/css" medi a="screen" 

href="/css/job.css" /> 
<link rel="styl esheet" type="text/css" medi a="pri nt" 

href="/css/pri nt . ess" /> 

Le fichier de configuration view. yml definit egalement le layout de 
l'application. Par defaut, le nom est layout, et done Symfony decore 
chaque page avec le fichier 1 ayout. php. Le processus de decoration peut 
egalement etre desactive en fixant l'entree has_l ayout a false. 

Cela marche tel quel mais le fichier jobs . ess est toujours necessaire pour 
la page d'accueil tandis que le fichier job. ess est seulement requis pour 



la page de detail d'une offre. Le fichier de configuration view.yml est 
personnalisable pour chaque module de base. 

Le bout de code ci-dessous configure le fichier view.yml de l'application 
afin qu'il ne fasse appel qu'au fichier mai n . ess. 

Extrait du fichier apps/frontend/config/view.yml 

| stylesheets: [main. ess] 

Pour personnaliser la vue du module d'offres d'emploi, il suffit de creer 
un nouveau fichier view.yml dans le repertoire apps/f rontend/modules/ 
job/config/ : 

Contenu du fichier apps/frontend/modules/job/config/view.yml 

indexSuccess: 

stylesheets: [jobs. ess] 

showSuccess: 

stylesheets: [job. ess] 

Les sections indexSuccess et showSuccess correspondent aux noms des 
templates des actions index et show qui seront evoquees plus tard. 
Chaque constante de configuration se trouvant sous la section al 1 peut 
etre redefinie dans les nouvelles sections creees. La section speciale al 1 
permet de definir les parametres de configuration partages par 
l'ensemble des actions du module. 

Configurer la vue a l'aide des helpers de Symfony 

En regie generale, tout ce qu'il est possible de parametrer dans un fichier 
de configuration peut etre accompli de la meme maniere avec du code 
PHP. Par exemple, au lieu de creer un fichier view.yml specifique au 
module job, nous pouvons directement inclure une feuille de style 
depuis un template a l'aide du helper use_stylesheet() : 

| <?php use_stylesheet('main.css') ?> 

Utiliser ce helper dans le fichier layout. php pour charger des feuilles de 
style revient a inclure cette derniere de maniere globale pour chaque 
module de l'application. 

Choisir l'une ou l'autre des deux methodes est en fait une simple ques- 
tion de gout. Le fichier view.yml fournit une maniere de definir des 
parametres pour toutes les actions d'un module, ce qui est impossible 
dans un template. Par ailleurs, le fichier de configuration est totalement 
statique. En revanche, avoir recours au helper use_styl esheetQ est bien 



Important Principes de configuration 
dans Symfony 

Pour les differents fichiers de configuration de 
Symfony, le meme parametre peut etre modifie 
a plusieurs niveaux : 

• la configuration par defaut dans le 
framework ; 

• la configuration globale du projet (dans 
config/); 

• la configuration locale d'une application 
(dans apps/APP/conf i g/) ; 

• la configuration locale restreinte a un 
module (dans apps/APP/modul es/ 
MODULE/config/). 

En cours d'execution, le systeme de configura- 
tion fusionne toutes les valeurs des differents 
fichiers s'ils existent, et met en cache le resultat 
pour de meilleures performances. 
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plus flexible puisque chaque chose est a sa place, la definition des feuilles 
de style comme le code HTML. 

Tout au long de cet ouvrage, c'est le helper use_stylesheet() qui sera 
utilise. Le fichier apps/f rontend/modules/job/config/view.yml, qui 
vient tout juste d'etre ajoute, peut finalement etre supprime au profit de 
l'emploi du helper use_stylesheet() dans les templates du module job. 

Helper a ajouter en haut du fichier apps/frontend/modules/job/templates/ 
indexSuccess.php 

| <?php use_stylesheet(' jobs. ess') ?> 

Helper a ajouter en haut du fichier apps/frontend/modules/job/templates/ 
showSuccess.php 

| <?php use_stylesheet(' job. ess') ?> 

De la meme maniere, la configuration des JavaScripts est realisee grace a la 
section javascripts du fichier de configuration view.yml ou bien grace a 
l'appel du helper use_javascri pt() directement dans un template. 



Generer la page d'accueil des offres d'emploi 

Comme il l'a ete presente au chapitre 3, la page d'accueil des offres 
d'emploi est generee par Faction i ndex du module job. L'action i ndex est 
la partie Controleur de la page, et le template associe, i ndexSuccess . php, 
est la partie Vue. Le code ci-dessous rappelle la structure arborescente 
du module job genere pour 1' application frontend. 

apps/ 

frontend/ 
modules/ 
job/ 

actions/ 

actions. class. php 
tempi ates/ 

i ndexSuccess . php 

Ecrire le controleur de la page : Taction index 

Chaque action est representee par une methode d'une classe. Pour la 
page d'accueil du module job, la classe est jobActions (le nom du 
module suffixe par Actions) et la methode est executelndexO (execute 
suffixe par le nom de Faction). L'action index recupere toutes les offres 
d'emploi de la base de donnees comme le montre le code ci-dessous. 



Contenu du fichier apps/frontend/modules/job/actions/actions.class.php 

class jobActions extends sfActions 
{ 

public function executeIndex(sfWebRequest $request) 
{ 

$this->jobeet job "list = Doctrine: :getTab1e('3obeetDob') 
->createQuery('a') 
->execute() ; 

} 

// ... 

} 

II est temps d'etudier de plus pres ces quelques lignes de code. La 
methode executelndexO (le controleur) appelle la table JobeetDob pour 
creer une requete SQL qui recupere toutes les offres d'emploi. Cette 
derniere retourne un objet Doctrine_Conection - une liste d'objets 
JobeetJob - qui est assigne a la propriete objet jobeet_job_list. 

Toutes ces proprietes d'objet sont ensuite automatiquement transmises 
au template (la vue). En resume, le passage d'une variable du controleur 
a la vue est simple : il suffit de declarer une nouvelle propriete dans la 
classe d'actions. 

public function executeFooBar(sfWebRequest Srequest) 
{ 

$this->foo = 'bar' ; 

$this->bar = array( ' bar ' , 'baz'); 

} 

Ce code cree les variables $foo et $bar accessibles dans le template. 



Creer la vue associee a Taction : le template 

Par defaut, le nom du template associe a une action est deduit par Sym- 
fony grace a une convention : le nom de Faction suffixee par Success. 

Le template indexSuccess.php genere un tableau HTML pour toutes 
les offres d'emploi. Le code actuel du template est presente ci-dessous : 

Contenu du fichier apps/frontend/modules/job/templates/indexSuccess.php 

<?php use_stylesheet(' jobs. ess') ?> 

<hl>Dob List</hl> 

<table> 
<thead> 
<tr> 

<th>Id</th> 



<th>Category</th> 
<th>Type</th> 
<!-- more columns here --> 
<th>Created at</th> 
<th>Updated at</th> 
</tr> 
</thead> 
<tbody> 

<?php foreach ($jobeet job list as $jobeet job): ?> 

<tr> 
<td> 

<a href="<?php echo url for(' job/show?id=' .$jobeet job- 
>getld()) ?>"> 

<?php echo $jobeet job->getId() ?> 

</a> 
</td> 

<tdx?php echo $jobeet job->getCategoryId() ?></td> 
<tdx?php echo $jobeet job->getType() ?></td> 
<!-- more columns here --> 

<tdx?php echo $jobeet job->getCreatedAt() ?></td> 
<tdx?php echo $jobeet job->getUpdatedAt() ?></td> 
</tr> 

<?php endforeach; ?> 

</tbody> 
</table> 

<a href="<?php echo url_for(' job/new') ?>">New</a> 

Dans le code du template, l'instruction foreach itere a travers la liste 
d'objets JobeetJob ($ jobeet_job_l i st) et, pour chaque offre d'emploi, 
affiche la valeur des colonnes en sortie. Acceder a la valeur d'une colonne 
d'une table est aussi simple qu'un appel a une methode accesseur dont le 
nom commence par get, suivi du nom de la colonne en « Camel Case » 
(par exemple, la methode getCreatedAtO pour la colonne created_at). 

Personnaliser les informations affichees pour chaque offre 

Le code precedent de la vue affiche toutes les informations de l'objet 
JobeetJob. Neanmoins, toutes ne sont pas forcement pertinentes pour la 
page d'accueil du site Internet et c'est pour cette raison que seuls la situa- 
tion geographique, le nom de la societe et le type de poste seront affiches. 

Contenu du fichier apps/frontend/modules/job/templates/indexSuccess.php 
<?php use stylesheet(' jobs. ess') ?> 

<div id="jobs"> 

<table class="jobs"> 

<?php foreach ($jobeet job list as $i => $job): ?> 

<tr class="<?php echo fmod($i, 2) ? 'even' : 'odd' ?>"> 
<td class="location"x?php echo $job->getLocation() ?> 
</td> 



<td c1ass="position"> 

<a href="<?php echo url_for(' job/show?i d= ' . $job->getId()) ?>"> 
<?php echo $job->getPositionO ?> 

</a> 
</td> 

<td c1ass="company"x?php echo $job->getCompany() ?></td> 
</tr> 

<?php endforeach; ?> 

</table> 
</di v> 



Jobeet 



» 




Enter some keywords (city, country, position, ...) 



Paris, France 
Paris, France 



Web Developer 
Web Designer 



Sensio Labs 



Extreme Sensio 



About Jobeet 0 Full feed Jobeet API Affiliates 



JOLlCBt powerod by ^rcrcrc^ 




Figure 4-5 Page de listing des offres d'emploi 

La fonction url_for() appelee dans les templates sera presentee au cha- 
pitre suivant. En attendant, il s'agit juste de retenir que ce helper permet 
de generer des URLs internes ou externes. 
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Generer la page de detail d'une offre 



Creer le template du detail de I'offre 

A present, il est temps de personnaliser le template qui affiche le detail des 
offres d'emploi. Pour ce faire, nous allons editer le fichier show/Success . php 
et remplacer son contenu actuel par le code presente ci-apres. 

Contenu du fichier apps/frontend/modules/job/templates/showSuccess.php 

<?php use_styl esheet( 1 job. ess') ?> 
<?php use_hel per( 'Text ' ) ?> 

<div id="job"> 

<hl> <?php echo $job->getCompany() ?></hl> 
<h2> <?php echo $job->getLocation() ?></h2> 
<h3> 

<?php echo $job->getPosition() ?> 
<sma"ll> - <?php echo $job->getType() ?></smal"l> 
</h3> 

<?php if ($job->getLogo()) : ?> 
<div c1ass="logo"> 

<a href="<?php echo $job->getUr"l () ?>"> 

<img src="/up1oads/jobs/<?php echo $job->getLogo() ?>" 
alt="<?php echo $job->getCompany() ?> logo" /> 

</a> 
</di v> 
<?php endif; ?> 

<div c1ass="description"> 

<?php echo simple format text($job->getDescription()) ?> 

</di v> 

<h4>How to apply?</h4> 

<p c1ass="how_to„apply"x?php echo $job->getHowToApp1y() ?> 

</p> 

<div c1ass="meta"> 

<sma11>posted on <?php echo dateC'm/d/Y' , 

strtotime($job->getCreatedAt())) ?></sma11> 
</di v> 

<div sty1e="padding: 20px 0"> 

<a href="<?php echo url for(' job/edit?id=' .$job->getId()) ?>"> 
Edit 

</a> 
</di v> 
</di v> 



Mettre a jour Taction show 

Ce template utilise la variable $job, transmise par Taction, pour afficher 
les informations detaillees d'une offre d'emploi. La variable passee au 
template a ete renommee de $jobeet_job en $job ; ce meme change- 
ment doit done etre opere sur les deux occurrences de la variable pre- 
sentes dans le corps de Faction show. 

Detail de la methode executeShow() du fichier apps/frontend/modules/job/actions/ 
actions.class.php 

public function executeShow(sfWebRequest Srequest) 
{ 

$this->job = Doctrine: :getTab1e('JobeetJob')-> find($request->getParameter('id')) ; 
$thi s->forward404Unl ess ($thi s->job) ; 

} 

La description d'une offre d'emploi est formatee a l'aide du helper 
simple_format_text(). Celui-ci remplace les retours a la ligne par des 
balises <br/>. Ce helper appartient au groupe des helpers Text qui ne 
sont pas charges par defaut par le framework. Lappel au helper 
use_helper() permet de charger manuellement tous les helpers du 
groupe Text et de les rendre disponibles dans le template. 



JoDeet 




ASK F 


» 






Enter some keywords (city, country, position, ...) 





SENSIO LABS 



Paris, France 



Web Developer - full-time 



You've already developed websites with symfony and you want to 
work 

with Open-Source technologies. You have a minimum of 3 years 
experience in web development with PHP or Java and you wish to 
participate to development of Web 2.0 sites using the best 
frameworks available. 

How to apply? 

Send your resume to fabien.potencier [at] sensio.com 



SENSIOLABS ^ 



polled on 01/13/2009 



About Jobeet 



I Full feed Jobeet API Affiliates 



Figure 4-6 

Page de detail d'une offre d'emploi 
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Utiliser les emplacements pour modifier 
dynamiquement le titre des pages 

Pour le moment, le titre de toutes les pages est inscrit en dur dans le tag 
<title> du layout : 

Extrait du fichier apps/frontend/templates/layout.php 

| <ti tl e>Jobeet - Your best job board</ti tl e> 

Bien evidemment, il serait plus judicieux de determiner un titre plus 
explicite, compose du nom de la societe et de l'intitule du poste, pour 
chaque page detaillant une offre d'emploi. 

Dans Symfony, lorsqu'une zone du layout depend du template a afficher, 
il devient necessaire de declarer un emplacement {slot). 



Figure 4-7 

Principe de fonctionnement 
des slots dans Symfony 



layout 


■ 






layout 


■ 




■ 




slot 


■ 




slot 


1 






slot 


template 


1 


slot 


template 



Ajouter un slot au layout dans la balise <head> permet ainsi de definir un 
titre dynamique pour chaque page. 

Definition d'un emplacement pour le titre 

Extrait du fichier apps/frontend/templates/layout.php 

| <titlex?php include_s "lot ('title') ?></title> 

Chaque emplacement se definit par un nom (ici title) et est affiche au 
moyen du helper inc"lude_s"lot(). 

Fixer la valeur d'un slot dans un template 

Une fois que le slot est defini, sa valeur peut etre fixee depuis n'importe 
quel template a l'aide du helper s"lot(). Dans le cadre de cette applica- 
tion, il s'agit de definir la valeur du slot « title » afin de modifier dynami- 
quement le titre de chaque page. Pour ce faire, il suffit de modifier le 
fichier show/Success . php en lui ajoutant le code ci-dessous. 



Definition du titre de la page dans le fichier apps/frontend/modules/job/templates/ 
showSuccess.php 

<?php slot( 
'title' , 

sprintf('%s is looking for a %s', $job->getCompany() , $job- 
>getPosition())) 
?> 

Fixer la valeur d'un slot complexe dans un template 

Si le titre est complexe a generer, le helper slotO peut aussi etre 
employe sous la forme d'un bloc comme le montre le code ci-apres. 

Exemple de slot complexe dans le fichier apps/frontend/modules/job/templates/ 
showSuccess.php 

<?php slot('title') ?> 

<?php echo sprintf('%s is looking for a %s ' , $job- 
>getCompany() , $job->getPosition()) ?> 
<?php end_slot() ; ?> 

Declarer une valeur par defaut pour le slot 

Pour quelques pages comme la page d'accueil, nous avons seulement 
besoin d'un titre generique. Au lieu de repeter le meme titre encore et 
encore dans tous les templates, il est possible de declarer un titre par 
defaut dans le layout : 

Definition d'un titre de page web par defaut apps/frontend/templates/layoutphp 

<title> 

<?php if (!inc"lude_s"lot( , title')): ?> 

Jobeet - Your best job board 
<?php endif; ?> 

</title> 

Le helper include_slot() retourne true si le slot a bien ete defini. En 
somme, lorsque le contenu du slot title est fixe depuis un template, il 
est utilise ; sinon c'est le titre par defaut qui est retenu. 



Remarque A propos des helpers 

Jusqu'a maintenant, un certain nombre de helpers 
commencant par i ncl ude_ ont ete presentes. 
Ces fonctions generent le code HTML et, dans la 
plupart des cas, ont un helper associe get_ qui 
retourne exclusivement le contenu : 
<?php i ncl ude_slot(' title') ?> 
<?php echo get_slot(' title') ?> 

<?php include_stylesheets() ?> 
<?php echo get_stylesheets() ?> 
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Apropos Lafamille 
des methodes de Forward 

L'appel a forward404Unless() est equiva- 
lent a : 

$thi s->f orward404If ( ! $thi s->job) ; 
qui est similaire a : 
if (!$this->job) 
{ 

$this->forward404() ; 

} 

La methode forward404() elle-meme est sim- 
plement un raccourci pour : 
$this->forward(' default' , '404'); 
La methode forward() redirige vers une autre 
action de la meme application. Dans I'exemple 
precedent, il s'agit de Taction 404 du module 
default. Le module par defaut est livre avec 
Symfony et fournit les actions par defaut pour 
generer les pages 404, ainsi que les pages de con- 
trole d'acces et d'identification. 



Figure 4-8 

Page d'erreur 404 en environnement 
de developpement 



Rediriger vers une page d'erreur 404 
si Poffre n'existe pas 

La page d'une offre d'emploi est generee au moyen de l'action show, 
declaree dans la methode executeShowO du module job : 

Methode executeShowO de la classe apps/frontend/modules/job/actions/ 
actions.class.php 

class jobActions extends sf Actions 
{ 

public function executeShow(sfWebRequest Srequest) 
{ 

$this->job = Doctrine: :getTable(' JobeetJob') 

->find($request->getParameter('id')) ; 
$this->forward404Unless($this->job) ; 

} 

// ... 

} 

De la meme maniere que dans Faction index, la classe de la table 
Jobeetlob permet de retrouver une offre d'emploi, cette fois-ci grace a la 
methode find(). Le parametre de cette methode est l'identifiant unique 
d'une offre d'emploi, sa cle primaire. La section suivante expliquera 
pourquoi le code $request->getParameter('id') retourne la cle pri- 
maire de l'offre d'emploi. 

Si une offre d'emploi n'existe pas dans la base de donnees, l'ideal est de redi- 
riger l'utilisateur vers une page d'erreur 404. Pour ce faire, il suffit d'utiliser la 
methode forward404Unless(). Cette derniere prend un booleen comme 
premier argument et, s'il n'est pas a true, arrete le flot d'execution en cours. 
Les methodes forward arretent immediatement l'execution de Taction en 
cours en lancant une exception sfError404Exception, ce qui explique qu'il 
n'est pas necessaire de retourner de valeur ensuite. 

Comme pour toutes les exceptions lancees, la page affichee a l'utilisateur est 
differente en fonction de l'environnement (production ou developpement) : 



404 | Not Found I sfError404Exception 

This request has been forwarded to a 404 error page by the action "job/show" 

stack trace 

1. rtf) 

in SF_SYMFONY_UB_DIR/action/sfAction.dass.php line 89 „, 

86. { 

87. if ( I Scondition) 



/<4>h i •.W^niHa I «ma a a ana * 1 - 
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Oops! Page Not Found 

The server returned a 404 response. 



Did you type the URL? 

You may have typed the address (URL) incorrectly. Check it to make sure 
you've got the exact right spelling, capitalization, etc. 

Did vou follow a link from somewhere else at this site? 

La personnalisation de la page d'erreur 404 sera presentee plus loin dans 
cet ouvrage lorsqu'il sera temps de deployer l'application sur le serveur 
de production. 



Figure 4-9 

Page d'erreur 404 en environnement 
de production 



Comprendre r interaction client/serveur 

Lorsque Ton navigue sur les pages /job ou /job/show/id/1 dans un naviga- 
teur, un aller-retour avec le serveur web est effectue. Le navigateur 
envoie une requete et le serveur lui retourne une reponse. 

Nous avons deja vu que Symfony encapsulait la requete dans un objet 
sfWebRequest (vu dans la signature de la methode executeShow()). Le 
framework etant entierement oriente objet, la reponse est elle aussi un 
objet de la classe sfWebResponse. Lacces a l'objet reponse depuis une 
action se realise au moyen de l'instruction $thi s->getResponse(). 

Ces objets fournissent un certain nombre de methodes adequates pour 
acceder aux informations issues des fonctions et des variables globales de 
PHP. 



Choix de conception Pourquoi Symfony 
encapsule-t-il des fonctionnalites 
existantes de PHP ? 

Tout d'abord parce que les methodes du fra- 
mework sont plus puissantes que leurs equiva- 
lents en PHP. Ensuite, lorsque Ton teste une 
application, il devient beaucoup plus simple de 
simuler un objet requete ou un objet reponse 
que d'essayer de bricoler un programme avec 
des variables globales ou des fonctions PHP 
comme headerO, dont le comportement est 
occulte par le developpeur. 



Recuperer le detail de la requete envoyee au serveur 

La classe sfWebRequest encapsule les tableaux globaux $_SERVER, 
$_C00KIE, $_CET, $_P0ST, et $_FILES de PHP. 

Tableau 4-1 Liste des methodes disponibles de l'objet sfWebRequest 



Nom de la methode 


Equivalent PHP 


getMethodO 


$_SERVER[ ' REQUEST_METHOD ' ] 


getUri () 


$_SERVER[ ' REQUESTJJRI ' ] 


getRefererO 


$_SERVER[ ' HTTP_REFERER ' ] 


getHostO 


$_SERVER [ ' HTTP_H0ST ' ] 


getLanguagesO 


$_SERVER[ ' HTTP_ACCEPT_LANGUAGE ' ] 


getCharsetsO 


$_SERVER[ ' HTTP_ACCEPT_CHARSET' ] 
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Tableau 4-1 Liste des methodes disponibles de I'objet sfWebRequest (suite) 



Norn de la methode 


Equivalent PHP 


isXmlHttpRequestO 


$_SERVER[ ' X_REQUESTED_WITH ' ] 
== 'XMLHttpRequest' 


getHttpHeaderO 


$_SERVER 


getCookie() 


$_C00KIE 


i sSecure() 


& trnwrn r i i it — r r*c~ i ~i 

$_SERVER|_ HTTPS J 


getFilesO 


$_FILES 


getCetParameterO 


$_GET 


getPostParameter() 


$_POST 


getUrl Parameter^) 


$_SERVER['PATH_INFO'] 


getRemoteAddress() 


$_SERVER[ ' REMOTE_ADDR' ] 



Les parametres de la requete ont deja ete accedes en utilisant la methode 
getParameterO. Celle-ci retourne une valeur en provenance de la 
variable globale $_GET, $_P0ST, ou bien de la variable PATH_INF0. Si Ton 
souhaite s'assurer qu'un parametre provient bien d'une de ces variables, il 
faut alors avoir recours respectivement a l'une des methodes 
getGetParameter(), getPostParameter() et getUrl Parameter(). 

Le framework Symfony introduit aussi la methode i sMethod () qui permet 
de controler la methode HTTP utilisee ou de servir a restreindre une 
action a une methode specifique. C'est exactement ce qu'il se passe lorsque 
Ton manipule des formulaires. Grace a la methode isMethodO, on peut 
ainsi s'assurer directement dans Taction que la requete a ete correctement 
transmise a l'aide de la methode POST : $this->forwardUnless($request- 
> isMethod('POST')); 



Recuperer le detail de la reponse envoyee au client 

La classe sfWebResponseO encapsule les fonctions PHP header () et 
setrawcookie(). 

Tableau 4-2 Liste des methodes disponibles de I'objet sfWebResponse 



setCookieO 


setrawcooki e() 


setStatusCodeO 


header() 


setHttpHeader() 


header() 


setContentType() 


header() 


addVaryHttpHeader() 


headerO 


addCacheContro1HttpHeader() 


header() 



Bien sur, la classe sfWebResponse fournit egalement une maniere de fixer 
le contenu de la reponse (setContentO) et d'envoyer cette derniere au 
navigateur (send()). 

Plus haut dans ce chapitre, nous avons decouvert comment gerer les 
feuilles de style et les JavaScripts aussi bien dans le fichier view.yml que 
dans les templates. Au final, les deux techniques s'appuient sur les 
methodes addStyleSheetO et addJavascri pt() de l'objet reponse. 

Les classes sf Action, sf Request et sf Reponse fournissent un lot d'autres 
methodes pratiques. N'hesitez pas a parcourir la documentation de 
l'API (http://www.symfony-project.org/api/1_2/) pour en savoir plus au sujet 
des classes internes de Symfony. 



En resume... 

Ce chapitre a permis de presenter deux motifs de conception integres 
dans Symfony pour repondre aux besoins d'organisation du code. 
L'arborescence des fichiers du projet prend maintenant tout son sens 
puisque chaque chose est idealement rangee a sa place. Dans la foulee, 
nous en avons profite pour apprivoiser la vue en manipulant le layout et 
les fichiers de templates. Certains d'entre eux ont d'ailleurs ete rendus 
dynamiques par l'intermediaire des slots et des actions. 

Le chapitre suivant presente le sous-framework de routage. Ce sera ainsi 
l'occasion d'en savoir un peu plus a propos du helper url_for() qui a ete 
vaguement apercu et mis en ceuvre au cours de ce chapitre. 



chapitre 




********** 



* symfony requirements check * 



******************************** 



php.ini used by PHP: /apache2/php/etc/php.ini 



** Mandatory requirements ** 

OK requires PHP >■- 5.2.4 

OK php.ini: requires zend. zel_compatibility_mode set to off 

** Optional checks ** 

OK PDO is installed 

OK PDO has some drivers installed: sqlite2, sqlite, mysql 

OK PHP-XML module installed 

{{WARNING]] XSL module installed 

*** Install the XSL module (recommended for Propel) *** 



OK 


can 


use token get all() 


OK 


0 B D 


use mb strlen( ) 


OK 


c B B 


use iconv ( ) 


OK 


c B D 


use utf8 decode() 


OK 


B B ■ 


a PHP accelerator 


OK 


php. 


-ini: short_open_tag set to off 


OK 


php, 


ini: magic_quotes_gpc set to off 


OK 


php. 


ini: register_globals set to off 


OK 


php. 


ini: session. auto_start set to off 




MOTS-CLES : 



Toute ressource disponible sur un site web est identifiee 
au moyen d'une adresse Internet unique qui permet 
de l'atteindre. Ces URL jouent un role determinant 
dans la semantique et le referencement du site car elles 
apportent des informations utiles sur la ressource identifiee, 
et c'est pour cette raison qu'il est important de reflechir 
a la maniere dont elles seront implementees. 

Le framework Symfony integre parfaitement un mecanisme 
interne puissant de gestion des « URLs propres ». 



► Routage 

► URL propres 

► Objets sfRoute 

et sfDoctrineRoute 



Le chapitre precedent a permis de decouvrir et de se familiariser avec 
l'architecture MVC qui devient avec la pratique une maniere de coder de 
plus en plus naturelle. C'est en s'exercant davantage avec cette methode 
de conception que Ton s'apercoit a quel point il est delicat de s' organiser 
autrement... Le chapitre 3 a egalement permis de s'entrainer un peu 
plus en personnalisant certaines pages de Jobeet, mais aussi de revoir 
plusieurs concepts importants de Symfony comme le layout, les helpers 
ou encore les slots. A present, il est temps de s'interesser a un autre outil 
indispensable de Symfony : le framework de routage. 

A la decouverte du framework de routage 
de Symfony 

Rappels sur la notion d'URL 

En cliquant sur la page detaillee d'une offre d'emploi, FURL ressemble a 
/jobs/show/id/1. Pourtant, les developpeurs d'applications web PHP 
traditionnelles sont generalement plus familiers des URLs parametrees 
telles que /job.php?id=l. Comment Symfony est-il capable de se com- 
porter de la sorte avec les URLs ? Comment le framework determine-t- 
il Taction a executer d'apres cette URL ? Pourquoi l'identifiant d'une 
offre d'emploi est-il recupere avec $request->getParameter('id') ? Ce 
sont toutes les questions auxquelles repond ce cinquieme chapitre. Pour 
commencer, il est important de rappeler ce qu'est une URL dans le con- 
texte du Web en general, et quel role elle joue exactement. 

Qu'est-ce qu'une URL ? 

Dans le contexte du Web, une URL est l'identifiant unique d'une res- 
source accessible depuis un navigateur web (une page HTML, une 
image, un fichier texte, une video...). Schematiquement, lorsqu'un utili- 
sateur saisit une adresse Internet dans son navigateur, il demande a ce 
dernier de lui recuperer la ressource distante identified par cette URL. 
Par consequent, une URL se comporte comme une interface entre le site 
Internet et l'utilisateur, et peut ainsi vehiculer des informations utiles au 
sujet de la ressource quelle reference. 

Or, un probleme se pose avec les URLs parametrees « traditionnelles » 
puisqu'elles ne decrivent pas veritablement la ressource distante et expo- 
sent, par la meme occasion, l'implementation technique interne de 
l'application. L'utilisateur se moque eperdument de savoir que le site 
Internet qu'il consulte est developpe avec le langage PHP, ou bien que 



chaque offre d'emploi est identifiee par un numero unique dans la base 
de donnees. La seule chose qui Finteresse, c'est d'acceder a la ressource 
qu'il desire grace a cette URL. 

Exposer les implementations techniques internes de l'application se revele 
par ailleurs particulierement dangereux pour la securite de celle-ci. En 
effet, quels seraient les eventuels degats provoques si un utilisateur mal- 
veillant arrivait a deviner FURL de ressources auxquelles il n'a pas le droit 
d'acceder ? Bien evidemment, c'est le role du developpeur de securiser de 
la meilleure maniere possible son application, mais il reste toujours prefe- 
rable de limiter les risques en cachant les informations sensibles. 

Introduction generate au framework interne de routage 

Au final, les adresses Internet sont si importantes dans Symfony qu'un 
framework entier leur est consacre : le framework de routage. Le sys- 
teme de routage gere a la fois les URLs internes et externes. Lorsqu'une 
requete entrante parvient au controleur frontal de l'application, celui-ci 
delegue le travail d'analyse de FURL au framework interne de routage 
qui se charge de la convertir en une requete interne comme celle de la 
page d'une offre d'emploi, dans le template showSuccess.php. 

'job/show?! d=' .$job->getId() 

Le helper url_forO convertit une URL interne en une URL propre : 
| /job/show/id/1 

Une URL interne par defaut est composee de plusieurs parties : tout 
d'abord le module job, suivi de Faction show et enfin de la chaine de 
requete qui contient les parametres a passer a Faction. Le motif gene- 
rique d'une URL interne suit le format suivant : 

| M0DULE/ACTI0N?key=va1ue&key_l=value_l&. . . 

Le framework de routage de Symfony est bidirectionnel, ce qui signifie 
que toutes les URLs peuvent etre modifiees sans avoir a changer leur 
implementation technique. C'est Fun des principaux avantages du motif 
de conception Front Controller. 

Configuration du routage : le fichier routing.yml 
Decouverte de la configuration par defaut du routage 

La configuration de toutes les URLs d'une application Symfony se situe 
dans un seul et meme fichier de configuration YAML : le fichier 



routi ng . yml . Celui-ci permet en effet de definir toute la carte des URLs 
internes de 1' application de maniere tres simple. C'est ce qui fait aussi 
que le framework de routage est bidirectionnel puisque la modification 
de la configuration d'une URL dans ce fichier n'impactera pas son 
implementation technique dans les templates ou dans les actions du 
projet. Le code ci-dessous decrit le contenu par defaut de ce fichier. II 
s'agit de la declaration des routes des trois motifs d'URLs necessaires au 
fonctionnement de base du framework. 

Configuration par defaut du routage dans le fichier apps/frontend/config/ 
routing.yml 

i homepage: 
url : / 

param: { module: default, action: index } 

default_index: 
url : / :module 
param: { action: index } 

default: 

url: /: module/: action/* 

Le fichier routing.yml decrit toutes les routes de l'application a l'aide 
d'une syntaxe YAML particulierement simple. En effet, une route se 
declare au minimum avec trois parametres. Le premier d'entre eux est 
tout d'abord le nom donne a la route (homepage) afin d'y faire reference 
dans les actions et les templates lors de son implementation technique. 

Le deuxieme parametre (url) determine bien evidemment le motif que 
doit prendre FURL dans son implementation finale. Par exemple, le 
motif /: module/: action/-' indique que l'adresse Internet est composee 
d'une barre oblique, suivie d'une valeur pour la variable module, elle 
meme suivie d'une barre oblique et d'une valeur pour la variable action , 
et enfin d'une derniere barre oblique suivie d'un caractere etoile qui 
indique au framework de routage que la route accepte une serie de para- 
metres supplementaires facultatifs. 

Enfin, le dernier parametre (param) est un tableau associatif dans lequel 
sont declarees les valeurs par defaut de certaines variables propres a 
FURL. Par exemple, la route homepage force le framework de routage a 
executer Faction index du module default en guise de page d'accueil. 
Les sections qui suivent abordent plus en detail tous ces aspects de con- 
figuration des routes de l'application. 



Comprendre le fonctionnement des URL par defaut de Symfony 

Lorsqu'une requete arrive sur le controleur frontal, le systeme de routage 
tente de lui faire correspondre un motif d'URL. La premiere route iden- 
tifiee l'emporte, ce qui signifie que l'ordre de declaration des routes dans 
le fichier routing. yml est important. Void quelques exemples pour 
mieux comprendre comment cela fonctionne. 

Quand un utilisateur demande la page d'accueil des offres d'emploi, 
dont l'URL est / job, la premiere route qui correspond a ce motif est en 
effet def aul t_i ndex. Dans un motif, un mot prefixe par deux points : est 
en fait une variable. Par consequent, le motif /: module signifie : « trouve 
un / suivi par quelque chose qui sera ensuite stocke dans la variable 
module ». Dans cet exemple, la variable module prend pour valeur job et 
peut ensuite etre retrouvee dans Faction grace a l'instruction Srequest- 
>getParameter('module'). Cette route definit aussi une valeur par 
defaut pour la variable action. Ainsi, pour toutes les URLs identifiables 
avec cette route, la requete disposera d'un parametre action dont la 
valeur est i ndex. 

Si la page /job/show/i d/1 est demandee, Symfony fera correspondre son 
URL au dernier motif : /: module/: action/-. Dans un motif, l'etoile * 
indique une collection de paires variable/valeur separees par des barres 
obliques /. 



Tableau 5-1 Liste des parametres et valeurs de l'URL de la page d'une offre d'emploi 



Parametre 


Valeur 


module 


job 


action 


show 


id 


1 



L'URL /job/show/i d/1 peut etre creee depuis un template en ayant 
recours a l'appel au helper url_forO suivant : 

I url_for(' job/show?id=' . $job->get!d()) 



Le meme resultat est egalement possible a partir du nom de la route pre- 
frxe par un arobase @ : 

| url_for('@default?id=' . $job->getId()) 

Les deux appels sont equivalents, mais le dernier est nettement plus per- 
formant. En effet, le framework de routage ha pas besoin d'analyser 
chaque route pour determiner celle qui correspond le mieux. De plus, il 
est moins lie a i'implementation du nom du module et de Taction 
puisque leur valeur respective est absente de l'URL interne. 



Remarque 

Les variables speciales module et action 

Les variables module et action sont speciales 
puisqu'elles sont utilisees par Symfony pour deter- 
miner Taction a executer. 
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Personnaliser les routes de Implication 



Configurer la route de la page d'accueil 

Pour l'instant, la page d'accueil de 1' application Jobeet est toujours celle 
par defaut de felicitations de Symfony. C'est en effet parce que l'adresse 
Internet interne / correspond a la route homepage definit dans le fichier 
de configuration routi ng . yml . II faut done remplacer cette page d'accueil 
par defaut au profit de celle de Jobeet. Pour ce faire, il suffit d'editer la 
configuration initiale de la route homepage en remplacant la valeur de la 
variable module par job. 

Configuration de la page d'accueil de Jobeet dans le fichier apps/frontend/config/ 
routing.yml 

homepage : 
url: / 

param: { module: job, action: index } 

Ceci etant fait, le lien figurant sur le logo de chaque page de Jobeet peut 
egalement etre edite afin d'appliquer FURL vers la page d'accueil de 
l'application. 

Definition du lien vers la page d'accueil dans le fichier apps/frontend/templates/ 
layout, php 

<hl> 

<a href="<?php echo url for (' ©homepage') ?>"> 

<img src="/i mages/ jobeet.gif" al t="Jobeet Dob Board" /> 

</a> 
</hl> 

Configurer la route d'acces au detail d'une offre 

La modification de la configuration d'une URL n'implique que de 
changer certains parametres dans le fichier de configuration 
routi ng . yml . Lobjectif a present est d'aller de l'avant en transformant le 
motif de FURL qui mene au detail d'une annonce, afin que cette adresse 
embarque davantage d'informations utiles comme le nom de la societe, 
la ville ou bien encore le type de poste propose. Cela permet a la fois de 
deviner par avance a quoi s'attendre en atteignant cette URL, mais aussi 
d'optimiser le referencement du site aupres des moteurs de recherche qui 
indexent les mots-cles qu'ils trouvent dans les adresses Internet. Le nou- 
veau motif des URLs de chaque offre correspondra a celui ci-dessous : 

/job/sen si o-l abs/pari s-f rance/l/web-devel oper 



Grace a ce motif, l'utilisateur ne connaissant absolument rien de Jobeet 
est capable de comprendre que la societe parisienne Sensio Labs est a la 
recherche d'un nouveau developpeur web. Cette URL est certes plus 
longue que celle par defaut mais elle a l'avantage d'etre bien plus perti- 
nente et semantique. 

/job/ : company/ : 1 ocati on/ : i d/ : posi ti on 

Pour y parvenir, il faut bien entendu modifier le contenu du fichier de 
configuration routing. yml afin de lui ajouter une route supplementaire 
job_show_user dont la configuration est donnee dans le code ci-apres. 
Le motif de cette route fait etat de quatre variables separees les unes des 
autres par des barres obliques. Les variables company, location, id et 
position representent respectivement le nom de la societe, le lieu, 
l'identifiant unique et le type de poste propose pour l'offre courante. 

job_show_user: 

url : /job/: company/: location/: id/: position 
param: { module: job, action: show } 

En rafraichissant de nouveau la page d'accueil, les liens vers les pages 
respectives des offres d'emploi n'ont pas change. C'est en effet normal 
etant donne que la route accepte a present des parametres obligatoires 
qui doivent etre transmis au helper url_for() afin qu'il genere FURL 
adequate. Par consequent, la definition du helper url_for() dans le tem- 
plate indexSuccess.php du module job doit etre modifiee de la maniere 
suivante. 

url _for(" job/show?id=' . $job->getId() . '&company=' .$job- 
>getCompany() . 

'&location=' . $job->getLocation() . '&position=' .$job- 
>getPosition()) 

II est egalement possible d'exprimer une URL interne a l'aide d'un 
tableau associatif. 

url_for(array( 

'module' => 'job' , 

'action' => 'show', 

'id' => $job->getId(), 

'company' => $ job->getCompany() , 

'location' => $job->getl_ocation() , 

'position' => $job->getPosition() , 

)); 



Remarque De I'utilite des URLs propres 

Les URLs propres et bien formees sont importantes 
car elles vehiculent des informations a l'utilisateur. 
C'est aussi particulierement pratique lorsque Ton 
copie/colle I'URL dans un e-mail ou lorsqu'il s'agit 
d'optimiser un site Internet pour les moteurs de 
recherche qui se servent des mots-cles presents 
dans les URLs. 
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Remarque La methode 
sfWebRequest::isMethod() vs framework 
de routage 

Forcer une route a correspondre a certaines 
requetes HTTP n'est pas entierement equivalent a 
utiliser sfWebRequest : : i sMethodO dans 
les actions. En effet, dans le premier cas, le routage 
continuera de chercher une route correspondante si 
la methode ne correspond pas a celle attendue. 



Forcer la validation des parametres des URLs internes 
de ('application 

Pour des raisons evidentes de securite et d'aide au debogage, le premier 
chapitre a mis en evidence les notions de validation et de gestion des 
erreurs. Le systeme de routage n'echappe pas non plus a cette regie 
puisqu'il possede une fonctionnalite native de validation des parametres 
des URLs internes. La valeur de chaque variable d'une adresse interne 
ayant un format propre peut etre validee au moyen d'une expression 
reguliere, definie par i'intermediaire de la section requi rements de la 
configuration d'une route. 

job_show_user : 

url : /job/: company/ location/: id/ :position 
param: { module: job, action: show } 
requirements: 
-id: \d+ 

La section requi rements ci-dessus force la valeur de la variable id a etre 
une valeur numerique entiere strictement positive. Si ce n'est pas le cas, 
la route ne correspondra pas au motif. 

Limiter une requete a certaines methodes HTTP 

Chaque route configured dans le fichier routing. yml est convertie en 
interne sous la forme d'un objet de la classe sfRoute. II arrive parfois 
qu'il faille ecrire des routes plus complexes se comportant differemment 
des routes traditionnelles. Par consequent, la classe sfRoute doit etre 
remplacee par une classe plus specifique. 

Lentree class de la configuration des routes du fichier routing. yml 
permet au developpeur de modifier le nom de la classe a utiliser pour 
controler les comportements de l'URL interne courante. Par exemple, le 
lecteur familier du protocole HTTP sait que celui-ci accepte les 
methodes GET, POST, HEAD, DELETE ou encore PUT, bien que les navigateurs 
web ne supportent que les trois premieres. Par consequent, il mesure 
tout l'interet de pouvoir limiter l'utilisation d'une requete HTTP pour 
une ou plusieurs de ces methodes. 

En remplacant la classe sfRoute par la classe sfRequestRoute et en ajou- 
tant une contrainte a la variable virtuelle sf_method, le framework 
interne de routage force la route a n'employer que certaines methodes de 
requetes HTTP. Comme les methodes HEAD et PUT ne sont pas suppor- 
tees par les navigateurs web modernes, le framework Symfony est 
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capable d'emuler leur comportement grace notamment a l'utilisation de 
cette variable speciale sf_method. 

job_show„user: 

url : /job/: company/: location/: id/: position 
class: sfRequestRoute 
param: { module: job, action: show } 
requi rements : 
id: \d+ 

sf method: [get] 

Optimiser la creation de routes grace a la dasse de 
route d'objets Doctrine 

La nouvelle URL interne pour les offres d'emploi est particulierement 
longue et fastidieuse a ecrire puisqu'il est necessaire de passer l'integralite 
des parametres obligatoires a la route par le biais du helper url_for(). 
Hormis le fait quelle soit contraignante a ecrire, elle dispose d'un second 
inconvenient tout aussi ennuyeux. En effet, l'implementation technique 
de la route et sa declaration dans le fichier de configuration routing. yml 
sont fortement couplees, ce qui implique que des modifications dans le 
parametrage de l'URL affecteront aussi l'implementation technique 
dans les templates et les actions. Par exemple, si un nouveau parametre 
est ajoute au motif de FURL, alors il faudra penser a modifier tous les 
templates et les actions pour passer la valeur de ce dernier. Ce n'est ni 
pratique ni interessant pour gagner du temps. 

Transformer la route d'une offre en route Doctrine 

Lideal est done de se tourner vers une approche differente de la creation 
d'URLs complexes. La section precedente a montre comment il etait 
simple de modifier la maniere dont est geree une route en modifiant le 
nom de sa classe associee. De ce fait, il convient d'avoir recours a la 
classe sfDoctri neRoute pour manipuler la route job_show_user, dans la 
mesure ou cette classe est optimisee pour representer n'importe quel 
objet Doctrine ou n'importe quelle collection d'objets Doctrine. 

job_show_user : 

url : /job/:company/:location/ :id/ :position 
class: sfDoctri neRoute 

options: { model: JobeetJob, type: object } 

param: { module: job, action: show } 
requi rements : 
id: \d+ 

sfjnethod: [get] 



ASTUCE Choisir le bon appel a url for() 

Le premier des deux appels a url_for() pre- 
sents ici est plus pratique lorsqu'il s'agit de trans- 
mettre des parametres supplementaires autres que 
I'objet relatif a la route Doctrine lui-meme. 



Remarque 

Qu'est-ce que la creation de slugs ? 

L'action de realisation d'un slug a partir d'une 
chame de depart consiste a transformer cette der- 
niere en vue de la reutiliser dans une URL comme 
identifiant d'une ressource ou seulement comme 
mots-cles supplementaires pour vehiculer de 
I'information au sujet de la ressource identified. 
Cette technique apporte de nombreux avantages 
pour une URL car elle permet a la fois de rendre 
cette derniere plus claire, plus lisible mais surtout 
plus semantique pour I'utilisateur. D'autre part, les 
mots-cles qu'elle vehicule participent a I'optimisa- 
tion de I'indexation du site Internet aupres des 
moteurs de recherche. 



La section options personnalise le comportement de la route. Ici, 
l'option model indique la classe de modele (jobeetJob) relative a la route, 
tandis que l'option type precise que la route est liee a un objet. Si la 
valeur de l'option type est list alors la route se rapportera a une collec- 
tion d'objets. 

La route job_show_user est maintenant informee de sa relation avec la 
classe de modele JobeetDob, ce qui permet de simplifier l'appel a 
url_for() par : 

url_for(array( ' sf_route' => ' job_show_user ' , ' sf_subject ' => 
$job)) 

Ou encore tout simplement : 
url_for(' job_show_user' , $job) 

Ameliorer le format des URL des offres d'emploi 

Limplementation de la route Doctrine precedente fonctionne telle 
quelle car toutes les variables qui se trouvent dans le motif de l'URL dis- 
posent en realite d'un accesseur correspondant dans la classe DobeetDob. 
Par exemple, la valeur de la variable company est rendue automatique- 
ment a l'appel implicite a la methode getCompanyO. Toutefois, les URLs 
generees pour certaines offres ne sont pas veritablement celles desirees 
puisque en effet certaines donnees comme la localisation ou bien le type 
de poste contiennent des caracteres non standards pour une URL. 

http://jobeet. local host/f rontend_dev.php/job/Sensi o+Labs/ 
Paris%2C+France/l/Web+Developer 

II apparait done necessaire de transformer a la volee les valeurs de ces 
colonnes en remplacant tous les caracteres non ASCII par des tirets - 
afin d'obtenir ce qu'on appelle des « slugs » dans le jargon informatique. 
N'ayant pas de veritable traduction courte en francais, le terme slug sera 
employe tout au long de cet ouvrage pour designer une chaine optimisee 
pour une URL. Pour ce faire, de nouvelles methodes doivent etre ajou- 
tees a la classe JobeetJob. 

Methodes a ajouter a la classe JobeetJob dans le fichier lib/model/doctrine/ 
JobeetJob.class.php 

public function getCompanySl ug() 
{ 

return Jobeet: : si ugi fy($thi s->getCompany()) ; 

} 
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public function getPositionSlugO 
{ 

return Jobeet: :slugify($this->getPosition()) ; 

} 

public function getLocationSlugO 
{ 

return Jobeet: :slugify($this->getLocation()) ; 

} 

Ces trois methodes font appel a une nouvelle classe Jobeet dans laquelle 
se trouve une methode statique slugifyO. C'est cette methode qui se 
charge de transformer une chaine de caracteres d'origine sous la forme 
d'une chaine simplified et optimisee pour une URL. II convient done de 
creer le fichier lib/Jobeet.class.php dans lequel est implemented cette 
nouvelle classe Jobeet. 

Implementation de la classe Jobeet dans le fichier lib/Jobeet.class.php 

<?php 

class Jobeet 
{ 

static public function slugify(Stext) 
{ 

// replace all non letters or digits by - 
Stext = preg_replace('/\W+/' , Stext) ; 

// trim and lowercase 

Stext = strtolower(trim($text, '-')); 

return Stext; 

} 

} 

La derniere etape consiste a remanier la definition de la route 
job_show_user afin que celle-ci fasse desormais usage des trois nouveaux 
accesseurs virtuels de la classe JobeetJob a la place des trois accesseurs 
actuels. La modification de la route consiste en fait uniquement a 
changer les noms des parametres dans le motif de FURL sans avoir a 
modifier quoi que ce soit dans le template. 

Edition de la route job_show_user dans le fichier de configuration apps/frontend/ 
config/routing.yml 

job_show_user : 

url : /job/: company slug/ location slug/ :id/:position slug 

class: sfDoctrineRoute 

options: { model: JobeetJob, type: object } 
param: { module: job, action: show } 



Remarque 

Suppression des balises PHP <?php 

Tout au long de cet ouvrage, les balises d'ouver- 
ture de script PHP <?php seront volontairement 
omises dans les morceaux de code presented. C'est 
en fait tout simplement par economie de place et 
pour rendre le code plus agreable a lire en retirant 
le « bruit » que generent ces balises. Toutefois, 
elles sont obligatoires a I'execution des scripts PHP 
par le serveur. II faut done prendre garde a ne pas 
les oublier lors de la ^implementation des codes 
presentes. 
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requi rements : 
id: \d+ 

sf_method: [get] 

II ne reste plus qua vider le cache de Symfony (commande symf ony cc), 
etant donne qu'une nouvelle classe Jobeet a ete ajoutee au projet, afin de 
pouvoir constater la transformation des chaines de caracteres passees 
dans les URLs des offres d'emploi. 

http : //jobeet . 1 ocal host/f rontend_dev . php/job/sensi o-l abs/pari s- 
f rance/l/web-developer 

Retrouver I'objet grace a sa route depuis une action 

La puissance du framework de routage se trouve encore au-dela des con- 
cepts etudies jusqu'a present. En effet, la route est capable de generer 
une URL basee sur un objet, mais aussi de recuperer celui-ci grace a 
I'objet sfDoctri neRoute. Lobjet lie peut alors etre retrouve en utilisant la 
methode getObject() de I'objet de la route Doctrine. Lorsque le sys- 
teme de routage analyse une requete entrante, il garde en memoire 
I'objet de la route correspondante afin de l'utiliser dans les actions. Ainsi, 
la methode executeShowO est desormais en mesure de retrouver I'objet 
JobeetJob grace a I'objet de la route Doctrine. 

Extrait de la methode executeShowO dans le fichier apps/frontend/modules/job/ 
actions/actions.class.php 

! class jobActions extends sf Actions 
{ 

public function executeShow(sfWebRequest Srequest) 
{ 

$this->job = $this->getRoute()->getObject() ; 

$thi s->forward404Unl ess($thi s->job) ; 

} 

// ... 

} 

Lappel a la methode getObjectO de I'objet de la route Doctrine lance 
une exception si I'objet Doctrine lie n'existe pas, ce qui provoque une 
page d'erreur 404 dont le message d'erreur est different de celui renvoye 
habituellement en environnement de developpement comme le montre 
la capture d'ecran un peu plus bas. Par consequent, le corps de la 
methode executeShowO peut etre simplifie puisqu'il n'est plus necessaire 
de gerer soi-meme la redirection vers une page d'erreur 404 lorsque 
aucun objet n'est renvoye. 



Simplification de la methode executeShow() dans le fichier apps/frontend/modules/ 
job/actions/actions.class.php 

class jobActions extends sfActions 
{ 

public function executeShow(sfWebRequest Srequest) 
{ 

$this->job = $this->getRoute()->getObject() ; 

} 

// ... 

} 



404 | Not Found I sfError404Exception ' 

Unable to find the JobeeUobPeer object with the following parameters "array ( 
'company as slug' => 'extreme-sensio', 'location_as_slug' => 'paris-france', 'id' 
=> '888', 'position_as_slug' => 'web-designer',)"). 

stack trace 

1. at() 

in SF_SYMFONY_UB_DlR/roubng/sfObjectRoute.class.php line 111 „. 

108. // check the related object 

109. if ( iB_null ( S this->object ■ $ this->get0b3ec tForParametera ( S thia->paranie t 

Figure 5-1 Page d'erreur 404 d'une route Doctrine en environnement de developpement 



Faire appel au routage depuis les actions et les templates 



Le routage dans les templates 

Dans un template, le helper url_for() convertit une URL interne en 
une URL externe. D'autres helpers Symfony prennent aussi une URL 
interne comme argument, comme le helper link_to() qui genere une 
balise HTML <a>. 

| <?php echo link_to($job->getPosition() , ' job_show_user' , $job) ?> 

La portion de code ci-dessus genere le code HTML suivant : 

<a href="/job/sensio-l abs/pari s-f rance/l/web-developer">Web 
Developer</a> 

Les deux helpers url_for() et link_to() peuvent produire des URLs 
absolues si on leur fournit un nouveau parametre booleen facultatif. 

url_for( ' job_show_user 1 , $job, true); 

link_to($job->getPosition() , 1 job_show_user ' , $job, true); 



ASTUCE Desactiver la levee des exceptions 
de la methode getObject() 

Pour eviter que la methode getObject() ne 
leve une erreur 404, I'option al 1 ow_empty 
peut etre definie a la valeur true dans la configu- 
ration de la route. 



Remarque enlargement a la demande 
de I'objet Doctrine d'une route 

L'objet lie a la route est charge a la demande, 
e'est-a-dire qu'il est recupere de la base de don- 
nees uniquement lorsque la methode 
getRouteQ estappelee. 
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Le routage dans les actions 

Le routage trouve aussi sa place dans les actions lorsqu'il s'agit par 
exemple d'effectuer une redirection automatique vers une page de 
l'application apres que I'utilisateur a realise une operation, comme le 
remplissage d'un formulaire. Les redirections sont rendues possibles 
depuis les actions par le biais de la methode redirectO tandis que la 
generation des URLs specifiques est realisee grace a la methode 
generateUrl (). 

$this->redi rect($thi s->generateUrl ( ' job_show_user ' , $job)) ; 



ASTUCE La famille des methodes de redirection 

Dans le precedent chapitre, il etait question des methodes de forward. Ces methodes trans- 
mettent la requete en cours a une autre action sans realiser d'echange avec le serveur. 
Les methodes de redirect redirigent I'utilisateur vers une autre URL. Comme pour forward, il 
est possible d'utiliser redirectO, ou ses raccourcis redirectlfO et 
redi rectUnlessQ. 



Decouvrir la classe de collection de routes 
sfDoctrineRouteCollection 

La route de Taction show du module d'offres d'emploi a deja ete person- 
nalisee, mais les URLs des autres methodes (index, new, edit, create, 
updated et delete) sont toujours gerees par la route par defaut. 

[ default: 

url : /:module/:action/* 

La route par defaut est un moyen tres pratique de commencer a coder 
sans definir trap de routes. Mais des lors que la route agit comme un 
catch-all (litteralement fourre-tout en francais), elle ne peut plus etre con- 
figured pour des besoins specifiques. 

Declarer une nouvelle collection de routes Doctrine 

Comme toutes les actions d'une offre d'emploi sont relatives a la classe 
de modele JobeetJob, il est possible de definir une route 
sfDoctrineRoute personnalisee pour chacune d'elles au meme titre que 
celle mise en ceuvre avec Taction show. Or, le module d'offres d'emploi 
definit sept actions de base possibles pour le modele. II est done prefe- 
rable d'avoir recours a la classe sfDoctrineRouteCol lection. Lutilisation 
de cette classe necessite de modifier le fichier routing, yml comme suit. 



Configuration d'une collection de routes pour I'objet JobeetJob dans le fichier apps/ 
frontend/config/routing.yml 



job: 

class: sfDoctri neRouteCollection 
options: { model: JobeetJob } 



job_show_user: 

url : /job/:company_slug/:location_slug/:id/:position_slug 
class: sfDoctri neRoute 

options: { model: JobeetJob, type: object } 
param: { module: job, action: show } 
requi rements : 
id: \d+ 

sf_method: [get] 

# default rules 
homepage : 
url : / 

param: { module: job, action: index } 



default_index: 
url : /:module 
param: { action: index } 

default: 

url: /:module/:action/* 

La route job ci-dessus nest qu'un simple raccourci qui genere automati- 
quement les sept routes sfDoctri neRoute suivantes : 

job: 

url: /job. : sf_format 

class: sfDoctri neRoute 

options: { model: JobeetJob, type: list } 

param: { module: job, action: index, sf_format: html } 

requirements: { sf_method: get } 



Remarque Routes identiques dans une 
collection de routes Doctrine 

Certaines routes generees par la classe 
sfDoctri neRouteCollecti on ont la 
meme URL. Le framework de routage est en fait 
capable de les utiliser car elles possedent toutes 
differentes methodes HTTP obligatoires. 



job_new: 

url: /job/new. : sf_format 
class: sfDoctri neRoute 

options: { model: JobeetJob, type: object } 

param: { module: job, action: new, sf_format: html } 

requirements: { sf_method: get } 

job_create: 

url: /job. :sf_format 
class: sfDoctri neRoute 

options: { model: JobeetJob, type: object } 

param: { module: job, action: create, sf_format: html } 

requirements: { sf_method: post } 



job_edit: 

url: /job/:id/edit. :sf_format 
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class: sfDoctri neRoute 

options: { model: JobeetJob, type: object } 

param: { module: job, action: edit, sf_format: html } 

requirements: { sf_method: get } 

job_update: 

url : /job/:id. :sf_format 
class: sfDoctri neRoute 

options: { model: JobeetJob, type: object } 

param: { module: job, action: update, sf_format: html } 

requirements: { sf_method: put } 

job^delete: 

url: /job/:id. :sf_format 
class: sfDoctri neRoute 

options: { model: JobeetJob, type: object } 

param: { module: job, action: delete, sf_format: html } 

requirements: { sf_method: delete } 

job_show: 

url: /job/:id. :sf_format 
class: sfDoctri neRoute 

options: { model: JobeetJob, type: object } 

param: { module: job, action: show, sf_format: html } 

requirements: { sf_method: get } 

Emuler les methodes PUT et DELETE 

Les routes job_delete et job_update necessitent 1'utilisation des 
methodes HTTP DELETE et PUT qui ne sont pas supportees par les navi- 
gateurs web. Neanmoins, ces URLs fonctionnent quand meme etant 
donne que Symfony arrive a les simuler a l'aide de la variable speciale 
sf_method. Le template _form.php donne un exemple d'implementation 
de ce mecanisme. 

Extrait du fichier apps/frontend/modules/job/templates/_form.php 
<form action^"..." ...> 

<?php if (!$form->get0bjectO->isNewO): ?> 

<input type="hidden" name="sf method" va1ue="PUT" /> 

<?php endif; ?> 

<?php echo link_to( 
'Delete' , 

' job/delete?id=' . $form->get0bject()->getld() , 
arrayC'method' => 'delete', 'confirm' => 'Are you sure?') 

) ?> 

Tous les helpers de Symfony sont capables d'emuler n'importe quelle 
methode HTTP lorqu'on leur passe le parametre special sf_method. Le 
framework possede d'autres parametres particuliers comme sf_method, 
qui debutent tous par le prefrxe sf_. Les routes generees plus haut dans 



cette section possedent toutes un - sf_format - qui sera presente a 
l'occasion d'un chapitre consacre aux services web. Le chapitre dedie a 
rinternationalisation et la localisation de Jobeet fera quant a lui usage de 
la variable speciale sf_culture. 



Outils et bonnes pratiques lies au routage 

Faciliter le debogage en listant les routes de 1'application 

Plus 1'application developpee grandit et plus le nombre de routes declarees 
croit, ce qui signifie aussi qu'il devient de plus en plus difficile de s'y 
retrouver entre les differentes URLs. C'est d'autant plus vrai lorsque 
1'application connecte des collections de routes Doctrine. En effet, les col- 
lections de routes Doctrine sont definies globalement dans le fichier de 
configuration routi ng . yml , mais la configuration des routes Doctrine uni- 
taires qu'elles renferment nest pas visible au travers de ce fichier. Par con- 
sequent, le debogage d'une route particuliere de 1'application peut se 
reveler plus complexe. Heureusement, le framework Symfony integre une 
tache automatique app: routes qui permet de connaitre l'integralite des 
routes connectees a 1'application comme en temoigne le resultat ci-apres. 

| $ php symfony app: routes frontend 

L'execution de cette commande produit un resultat comparable a celui 
en dessous. Cette liste donne pour chaque route connectee son nom, la 
methode qui restreint son acces, et bien sur son motif complet qui tient 
compte de la variable speciale sf_format presentee plus tard. 



» app 


Current routes for application "frontend" 


Name 




Method Pattern 


job 


GET 


/job. : sf_format 


job_new 


GET 


/job/new. :sf_format 


job_create 


POST 


/job . : sf_format 


job_edit 


GET 


/job/: id/edit. :sf_jformat 


job_update 


PUT 


/job/ :id. :sf_format 


job_del ete 


DELETE /job/:id. :sf_format 


job_show 


GET 


/job/ : id . : sf_format 


job_show_user GET 


/ j ob/ : company_sl ug/ : 1 ocati on_s1 ug/ : i d/ 


: position_ 


slug 




homepage 


ANY 


/ 



II est egalement possible d'obtenir de nombreuses informations de debo- 
gage pour une route donnee en passant son nom en tant que second 
parametre additionnel. 

$ php symfony app: routes frontend job_edit 



L'execution de cette commande a pour effet de produire le resultat sui- 
vant dans le terminal. Cette commande est particulierement interessante 
puisqu'elle donne tout le detail de la configuration de la route, y compris 
les parametres internes definis automatiquement par la classe 
sf Doctri neRoute. Les elements mis en exergue sont ceux qui ont deja ete 
vus tout au long de ce chapitre. 

» app Route "job_edit" for application "frontend" 

Name job_edit 
I Pattern /job/: id/edit. :sf format 

Class sfDoctri neRoute 

Defaults action: 'edit' 

module: 'job' 

sf_format: 'html' 
, Requirements id: '\\d+' 

sf_format: ' [A/\\.]+" 

sf method: 'get' 
Options context: array () 

debug: false 

extra_parameters_as_query_stri ng : true 

generate_shortest_url : true 

load_configuration: false 

logging: false 

method: NULL 

model: 'JobeetJob' 

object_model : 'lobeetlob' 

segment_separators: array (0 => '/',1 => '.',) 
segment_separators_regex: ' (?:/|\\.) ' 
suffix: " 
text_regex: ' .+?' 
type: 'object' 

vari abl e_content_regex : ' [a/\\ . ] + ' 
variable_prefix_regex: ' (?:\\:) ' 
vari abl e_prefixes: array (0 => ':',) 
vari abl e_regex : ' [\\w\\d_] + ' 
Regex #a 

/job 

/(?P<id>\d+) 
/edit 

(? : \ . (?P<sf_f ormat> [a/\ . ] +) 

)? 
$#x 

Tokens separator array (0 => '/',1 => NULL,) 

text array (0 => 'job',1 => NULL,) 

separator array (0 => '/',1 => NULL,) 

variable array (0 => ':id',l => 'id',) 

separator array (0 => '/',1 => NULL,) 

text array (0 => 'edit',1 => NULL,) 

separator array (0 => '.',1 => NULL,) 

variable array (0 => ' : sf_format ' , 1 => 'sf_format' ,) 



Supprimer les routes par defaut 



Une bonne pratique consiste a declarer une route specifique pour chaque 
URL de l'application, et a supprimer les routes par defaut afin d'empe- 
cher l'acces a des ressources pour lesquelles aucune route dediee n'aurait 
ete declaree dans le fichier de configuration routing. yml. Cela permet 
par exemple de se premunir des pirates qui tenteraient d'acceder a des 
modules de l'application non securises en passant par les routes par 
defaut qui correspondent a n'importe quel motif d'URL. 

Par consequent, comme la route job definit toutes les routes necessaires 
pour decrire l'application Jobeet, les routes par defaut du fichier de con- 
figuration routing. yml peuvent etre supprimees ou mises en commen- 
taire en toute securite. L'application Jobeet devrait continuer de 
fonctionner normalement comme avant. 

Deactivation des routes par defaut de l'application frontend dans le fichier apps/ 
frontend/config/routing.yml 

#default_index: 

# url : /:module 

# param: { action: index } 
# 

#default: 

# url: /: module/: action/* 



En resume... 

Ce chapitre a presente de nombreux concepts importants concernant le 
framework interne de routage de Symfony comme les routes par defaut, 
basiques, restreintes aux methodes HTTP, d'objets et de collections 
Doctrine, ou encore les collections de routes Doctrine. De plus, ces 
pages ont montre comment il est possible de creer des URLs elegantes et 
significatives avec Symfony, tout en les decouplant de leur implementa- 
tion technique. Tous ces aspects seront tres regulierement remis en 
oeuvre tout au long de cet ouvrage dans la mesure ou les URLs jouent un 
role fondamental dans une application web. 

Le chapitre suivant quant a lui n'introduit pas veritablement de nou- 
veaux concepts, ce qui permettra de revenir plus en detail sur une bonne 
partie des notions abordees jusqu'a present : le routage, l'architecture 
MVC, les objets Doctrine, le remaniement du code, etc. 



chapitre 



SQL queries Efl IMiM?! co-fg > logs □ 1706.3 KB 51 ms 1 .. 

SELECT jobeet lob. ID, jobeetjob. CATEGORY JD, jobeetJob.TYPE, jobeetjob. COMPANY, jobeetjob. LOGO, jobeet Job. URL, 

obeetjob. POSITION, jobeetjob. LOCATION, jobeetjob. DESCRIPTION. jobeetJob.HOW_TO_APPLY, jobeetjob. TOKEN, jobeetJob,IS_PUBLIC, 

obeetJob.CREATED_ AT, jobeet Job.UPDATED.AT FROM 'jobeet job' WHERE jobeet job.CR EATED_AT>:p1 [:p1 = '2 008- ■ ■ -06 ■ 5 :56:08') 



Optimisation du modele 
et refactoring 



La majeure partie du code metier d'une application MVC 
est conditionnee dans la couche du modele. Or, le volume 
de code du modele peut tres vite devenir un veritable casse-tete 
a maintenir et a perenniser. C'est pourquoi ce chapitre 
sera l'occasion de vous familiariser avec les techniques 
de factorisation et de simplification du code. 



MOTS-CLES : 

► Modele 

► Doctrine Query Language 

► Refactoring de code 



Le chapitre precedent a permis d'aborder la maniere de creer des URLs 
elegantes et de voir comment utiliser le framework Symfony pour auto- 
matiser de nombreuses choses. Dans les pages qui suivent, le site web 
Jobeet va etre ameliore en optimisant le code ici et la. Dans la foulee, les 
fonctionnalites abordees jusqu'a maintenant seront un peu plus detaillees. 



Presentation de I'objet Doctrine_Query 

Parmi les objectifs definis au chapitre 2 figure celui-ci : 

« Quand un utilisateur arrive sur le site web de Jobeet, il decouvre une 
liste des offres d'emploi actives ». 

Pour le moment, toutes les offres d'emploi sont affichees, qu'elles soient 
actives ou non. 

Contenu du fichier apps/frontend/modules/job/actions/actions.class.php 

class jobActions extends sf Actions 
{ 

public function executeIndex(sfWebRequest Srequest) 
{ 

$this->jobeet_job_list = Doctri ne : : getTabl e( ' JobeetJob ' ) 
->createQuery('a') 
->execute() ; 

} 

// ... 

} 

Une offre active est une offre qui a ete postee il y a moins de 30 jours. 
C'est la methode Doctri ne_Query: : execute () qui effectue une requete 
sur la base de donnees. Dans le code ci-dessus, aucune condition parti- 
culiere n'a ete specifiee, ce qui signifie que tous les enregistrements sont 
recuperes de la base de donnees. 

Avec Doctrine, l'ajout de conditions dans une requete SQL est realise a 
l'aide de la methode whereO, comme le montre le code modifie de la 
methode executelndexO de la classe JobActions : 

public function executeIndex(sfWebRequest Srequest) 
{ 

$q = Doctrine_Query: :create() 
->f rom( ' JobeetJob j') 

->where('j .created at > ?', dateC'Y-m-d h:i:s', 
+■ timeO - 86400 * 30)); 

$this->jobeet_job_list = $q->execute() ; 

} 



Deboguer le code SQL genere par Doctrine 



Dispensant d'avoir a ecrire les requetes SQL a la main, Doctrine fait 
attention aux differences entre les moteurs de bases de donnees, et 
genere les ordres SQL optimises pour le moteur configure au chapitre 3. 
Neanmoins, c'est parfois une aide indeniable que de pouvoir lire le code 
SQL genere par Doctrine ; par exemple, pour deboguer une requete qui 
ne fonctionne pas comme on l'attend. En environnement de developpe- 
ment, Symfony enregistre ces requetes (et bien plus encore) dans le 
fichier 1 og/f rontencLdev . 1 og. 

Decouvrir les fichiers de log 

Le repertoire 1 og/ stocke les fichiers de log par application et par envi- 
ronnement, ce qui permet de retrouver et de suivre facilement l'ensemble 
des operations internes effectuees par le framework lorsqu'une URL est 
demandee au serveur. 

Exemple de log dans le fichier log/frontend_dev.log 

Dec 04 13:58:33 symfony [info] {sfDoctri neLogger} executeQuery 
: SELECT 

j.id AS j id, j .category_id AS j category_id, j.type AS 

j_type, 

j. company AS j company, j.logo AS j logo, j.url AS j url , 

j. position AS j position, j. location AS j location, 

j .description AS j description, j . how_to_appl y AS 

j how_to_appl y , 

j. token AS j token, j.is_public AS j is_public, 

j . is_activated AS j i s_acti vated , j. email AS j email, 

j.expires_at AS j expires_at, j . created_at AS j created_at, 

j.updated_at AS j updated_at FROM jobeet_job j 

WHERE j.created_at > ? (2008-11-08 01:13:35) 

II est ainsi possible de controler que la requete generee par Doctrine pos- 
sede bel et bien une clause Where sur la colonne created_at (WHERE 
j . created_at > ?). 

Avoir recours a la barre de debogage 

Si l'acces a ces journaux d'evenements reste tres pratique, il ne demeure 
pas moins contraignant d'avoir a passer du navigateur a l'EDI 
(« environnement de developpement integre ») et au fichier de logs. 
C'est pourquoi Symfony comporte une barre de debogage afin de rendre 
disponibles depuis le navigateur toutes les informations pertinentes. 



Bonne pratique Les requetes preparees 
pour lutter contre les attaques par 
injections 

La chame « ? » dans la requete indique que 
Doctrine genere des requetes preparees. La 
valeur courante de «?» (« 2008-11-08 
01:13:35 » dans I'exemple ci-dessus) est passee 
au cours de I'execution de la requete afin d'etre 
traitee litteralement par le moteur de base de 
donnees. L'usage de requetes preparees reduit 
drastiquement I'exposition de I'application aux 
attaques par injections SQL. 
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SQL queries iHilila'l conllg # logs □ 1706.3 KB ©51ms : 1 j( 

SELECT jobeet Job.lD, jobeetjob.CATEGORY_ID, jobeetJob.TYPE. iobeetJob.COMPANY, iobeetJob.LOGO, jobeetjob.URL. 
jobeetJob.POSTriON.lobeetJob.LOCATION, jobeet Job. DESCRIPTION, jobeet job.HOWJTO^PPLY, jobeetJob.TOKEN, jobeetJob.lS_PUBLIC, 
]obeetjob.CREATED_AT, Jobeet Job. UPDATED . ATFROM 'jobeetjob' WHERE jobeet Job.CREATED_AT>:p1 (:p1 = '2008-1 1-06 1 5:56:08') 

Figure 6-1 Requetes SQL generees par Doctrine dans la barre d'outils de deboguage de Symfony 



Intervenir sur les proprietes d'un objet 
avant sa serialisation en base de donnees 

Meme si le code ci-dessus fonctionne, il est encore loin d'etre parfait 
dans la mesure ou il ne prend pas en compte certaines exigences telle que 
la suivante : 

« Un utilisateur peut revenir pour reactiver ou etendre la validite de 
l'annonce d'une offre d'emploi pour une nouvelle periode de 
30 jours... » 

Or, le code precedent s'appuie sur la valeur du champ created^at, et 
parce que cette colonne stocke la date de creation, il est impossible de 
satisfaire ce besoin. 



Redefinir la methode savc() d'un objet Doctrine 

Une colonne expi res_at a heureusement ete prevue dans le schema de 
base de donnees (voir chapitre 3). Pour l'instant, sa valeur n'est pas ren- 
seignee puisqu'elle n'est pas definie dans le fichier de donnees initiales. 
Mais lors de la creation d'une nouvelle offre d'emploi, cette colonne 
pourrait automatiquement prendre pour valeur la date courante du ser- 
veur, a laquelle une periode de 30 jours est ajoutee. 

Pour realiser une operation juste avant qu'un objet Doctrine ne soit 
serialise en base de donnees, il suffit de redefinir la methode save() de la 
classe de modele. 

Redefinition de la methode save() de I'objet dans le fichier lib/model/doctrine/ 
JobeeUob.class.php 

class Jobeetjob extends BaseJobeetJob 
{ 

public function save(Doctrine_Connection Sconn = null) 
{ 

if ($this->isNew() && !$this->getExpiresAt()) 
{ 

$now = $this->getCreatedAt() ? 

strtotime($this->getCreatedAtO) : timeQ; 
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$this->setExpiresAt(date('Y-m-d h:i :s' , 

$now + 86400 * 30)); 

} 

return parent: : save(Sconn) ; 

} 

// ... 

} 

La methode isNew() retourne true quand l'objet n'a pas ete serialise en 
base de donnees et f al se dans le cas contraire. 

Recuperer la liste des offres d'emploi actives 

II est maintenant necessaire de modifier Faction afin d'utiliser la colonne 
expi res_at au lieu de created_at pour selectionner les offres d'emploi 
actives. 

public function executeIndex(sfWebRequest Srequest) 
{ 

$q = Doctrine„Query: :create() 
->from(' JobeetDob j') 

->where('j .expires at > ?', date('Y-ni-d h:i:s', time())); 

$this->jobeet_job_1ist = $q->execute() ; 

} 

La requete est ainsi reduite a ne recuperer que les offres d'emploi ayant 
une valeur expi res_at dans le futur. 

Mettre a jour les donnees de test pour 
s'assurer de la validite des offres affichees 

Rafraichir la page d'accueil de Jobeet dans un navigateur ne changera 
rien puisque les offres d'emploi enregistrees en base de donnees n'ont ete 
postees que quelques jours plus tot. II est done obligatoire de changer les 
donnees de test pour ajouter une nouvelle offre d'emploi deja expiree. 

Offre d'emploi a ajouter au fichier data/fixtures/jobs.yml 

JobeetJob: 
# other jobs 

expi red_job: 

JobeetCategory : programming 
company: Sensio Labs 



Important Respecter I'indentation 
d'un fichier YAML 

II faut toujours veiller a ne pas rompre I'indenta- 
tion lorsque Ton copie et colle du code dans un 
fichier de donnees de tests. L'offre d'emploi 
expi red_job ne doit avoir que deux espaces 
qui la precedent. 
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is_public: 
i s_acti vated 
expi res at : 
token : 
emai 1 : 



position: 
location: 
description: 



how_to_apply 



Web Developer 
Paris, France 

Lorem ipsum dolor sit amet, consectetur 
adipisicing el it. 

Send your resume to lorem. ipsum [at] 

dolor. sit 

true 

true 

'2005-12-01 00:00:00' 

job_expi red 
jobOexampl e . com 



Dans la definition des champs de cette offre nouvellement creee, la valeur 
de la colonne created_at a ete redefinie explicitement - bien quelle soit 
automatiquement remplie par Doctrine. La valeur ainsi specifiee surchar- 
gera celle par defaut. En rechargeant les donnees de test, puis en rafrai- 
chissant le navigateur, 1' offre d'emploi expiree ne s'affichera pas. 

$ php symfony doctrine: data-load 

La requete SQL suivante permet de controler que la colonne expi res_at 
est bien remplie automatiquement par la methode save() a partir de la 
valeur de created_at. 

SELECT 'position', 1 created_at 1 , ~expires_at~ FROM 
' jobeet_job' ; 



Gerer les parametres personnalises d'une 
application dans Symfony 



Dans la methode JobeetJob: :save(), le nombre de jours restant avant 
qu'une offre d'emploi n'expire a ete code « en dur ». Or il vaudrait bien 
mieux rendre cette valeur configurable ailleurs - pour des raisons de faci- 
lite de maintenance et de genericite. La solution est toute trouvee avec le 
fichier de configuration app.yml qui permet de definir les parametres 
specifiques a une application. Ce fichier YAML, fourni par defaut par le 
framework Symfony, peut definir n'importe quel parametre. 

Decouvrir le fichier de configuration app.yml 

En regie generale, il est deconseille de fixer en dur dans un programme des 
informations qui peuvent etre configurees ailleurs. En effet, en centralisant 
les parametres dans un fichier commun, les modifications se font plus sim- 
plement et plus rapidement - autant de temps gagne en maintenance. 



Symfony fournit a cet usage un fichier dedie a la configuration d'une 
application. II s'agit du fichier apps/APPLICATION/config/app.yml . 

Exemple de fichier de configuration : contenu de apps/frontend/config/app.yml 

all : 

acti ve_days : 30 

Dans l'application, ces parametres sont disponibles au travers de la classe 
globale sfConfig. 

| sfConfig: : get( ' app_acti ve_days ' ) 

Recuperer une valeur de configuration depuis le modele 

Le parametre a ete prefixe par app_ parce que la classe sfConfig fournit 
aussi un acces aux parametres de Symfony comme il sera presente plus 
tard. Afin que ce nouveau parametre soit pris en compte, il est necessaire 
de modifier de nouveau la methode save() de l'objet DobeetJob. 

public function save(Doctrine_Connection $conn = null) 
{ 

if ($this->isNew() && ! $thi s->getExpi resAtO) 
{ 

Snow = $this->getCreatedAt() ? 

strtotime($thi s->getCreatedAt()) : time(); 
$this->setExpi resAt(date('Y-m-d h:i:s', Snow + 86400 * 

sfConfig: :get('app active days'))) ; 

} 

return parent :: save($conn) ; 

} 

Le fichier de configuration app . yml est un excellent moyen de centraliser 
les parametres globaux de l'application. Ceux-ci restent alors disponibles 
a tout moment et depuis himporte ou grace a la classe globale sfConfig. 



Remanier le code en continu pour respecter 
la logique MVC 

Le code ecrit fonctionne parfaitement, mais il n'est pas encore tout a fait 
correct. Ou se situe le probleme et comment le resoudre ? Le chapitre 4 
a montre comment le modele MVC separe le code en trois couches 
distinctes : le modele, la vue et le controleur. 



Tout au long du processus de developpement de Implication, il sera 
souhaitable de garder cette regie a l'esprit afin de penser a remanier du 
code, voire le deplacer ailleurs lorsque necessaire. 



E 



Exemple de emplacement du contrdleur vers le modele 

Le code de Doctri ne_Query n'appartient pas a Faction (la couche 
controleur) ; il depend en realite de la couche du modele. Dans le motif 
MVC, le modele definit toute la logique metier, e'est-a-dire celle qui 
manipule les donnees, tandis que le controleur ne fait qu'appeler celui-ci 
pour y recuperer des donnees, en fonction de la requete de l'utilisateur, 
qu'il communique ensuite a la vue. 

Dans le cas present, le code retourne une collection d'offres d'emploi en 
guise de resultat ; e'est pourquoi il convient de deplacer ce dernier dans 
la classe JobeetDobTable, dans laquelle on cree une methode 
getActi veJobs(). 

Contenu du fichier lib/model/doctrine/JobeetJobTable.class.php 

class JobeetJobTable extends Doctri ne_Tabl e 
{ 

public function getActi veJobs() 
{ 

$q = $this->createQuery(' j ') 

->where('j .expires at > ?', date( ' Y-m-d h:i:s', time())); 



return $q->execute() ; 



} 



A present, Taction peut utiliser cette nouvelle methode pour retrouver 
les offres d'emploi actives. 

public function executeIndex(sfWebRequest Srequest) 
{ 

$this->jobeet job list = 

Doctri ne : : getTabl e( ' Jobeet Job ' ) ->getActi veJobs () ; 

} 



Avantages du remaniement de code 

Ce remaniement du code apporte plusieurs benefices indeniables par 
rapport au code precedent. 

Les tests automatiques seront presentes au Tout d'abord, la logique de recuperation des offres d'emploi actives est 
chapitre 8. desormais a sa place dans le modele. De ce fait, le controleur est conside- 

rablement allege et rendu beaucoup plus lisible. D'autre part, ce rema- 
niement a rendu la methode getActi ve Jobs () reutilisable pour une 
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eventuelle prochaine utilisation. Enfin, le code est desormais disponible 
pour des tests unitaires. 

Ordonner les offres suivant leur date d'expiration 

Pour l'instant, toutes les offres sont recuperees et affichees dans Yordre de 
leur creation, c'est-a-dire en suivant la cle primaire. Or notre application 
doit montrer l'information la plus recente le plus souvent possible ; c'est 
pourquoi les offres doivent etre ordonnees suivant leur date d'expiration 
- de la plus lointaine dans le futur a la plus proche de la date courante. 

Le code suivant ordonne la liste des offres d'emploi suivant la colonne 
expi res_at. 

public function getActiveJobs() 
{ 

$q = $this->createQuery(' j ') 

->where(' j .expi res_at > ?', date( ' Y-m-d h:i:s', time())) 
->orderBy('j .expires at DESC); 

return $q->execute() ; 

} 

La methode orderBy determine la clause ORDER BY de la requete SQL 
generee. II est egalement possible d'utiliser addOrderByO pour effectuer 
un tri sur plusieurs colonnes. 

Classer les offres d'emploi selon leur categorie 

Parmi les objectifs definis au chapitre 2 figure celui-ci : 

« Les offres d'emploi sont ordonnees par categorie et ensuite par date de 
publication, des plus recentes aux plus anciennes ». 

Jusqu'a present, la categorie d'une offre n'a pas ete prise en compte. Or 
cette prise en compte fait partie du cahier des charges : la page d'accueil 
doit afficher les offres d'emploi par categorie. II est done necessaire de 
recuperer dans un premier temps toutes les categories ayant au moins 
une offre d'emploi active. Pour ce faire, une methode getWithJobsO doit 
etre ajoutee a la classe JobeetCategoryTable. 

Contenu du fichier lib/model/doctrine/JobeetCategoryTable.class.php 

class JobeetCategoryTable extends Doctri ne_Tabl e 
{ 

public function getWithJobsO 
{ 

$q = $this->createQuery('c') 
->1eftDoin('c.3obeet3obs j') 

->where(' j .expires_at > ?', date ('Y-m-d h:i:s', timeQ)); 



Remarque De I'utilite de la methode 
magique toStringO 

Pour afficher le nom de la categorie dans le 
modele, nous avons eu recours a 

echo Scategory 
Cela parait-il etrange ? Scategory est un 
objet, comment echo peut-il afficher le nom de 
la categorie ? La reponse a ete donnee au 
chapitre 3 lorsque nous avons defini la methode 

magique toStringO pour toutes les 

classes du modele. 



return $q->execute() ; 

} 

} 

L'action i ndex doit aussi etre modifiee en consequence : 

Detail de la methode executelndex() du fichier apps/frontend/modules/job/actions/ 
actions.class.php 

public function executeIndex(sfWebRequest Srequest) 
{ 

$this->categories = Doctrine: :getTable('JobeetCategory') 

->getWith3obs(); 

} 

Dans le template, les offres d'emploi actives sont desormais affichees en 
iterant a travers toutes les categories. 

Contenu du fichier apps/frontend/modules/job/indexSuccess.php 

<?php use_stylesheet(' jobs. ess') ?> 

■ <div id="jobs"> 

<?php foreach ($categories as Scategory): ?> 

<div dass="category_<?php echo Jobeet :: si ugi fy (Scategory 

->getName()) ?>"> 

<div class="category"> 
<div class="feed"> 

<a href="">Feed</a> 
</di v> 

<hlx?php echo Scategory ?></hl> 
</di v> 

<tab1e class="jobs"> 

<?php foreach ($category->getActive3obs() 
as $i => Sjob) : ?> 

<tr class="<?php echo fmod($i, 2) ? 'even' : 'odd' ?>"> 
<td c1ass="location"> 

<?php echo Sjob->getLocation() ?> 
</td> 

<td c1ass="position"> 

<?php echo 1ink_to($job->getPosition() , 

' job_show_user' , Sjob) ?> 

</td> 

<td c1ass="company"> 

<?php echo Sjob->getCompany() ?> 
</td> 
</tr> 

<?php endforeach; ?> 

</table> 
</di v> 
<?php endforeach; ?> 

</di v> 
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Pour que cela fonctionne, il est necessaire d'aj outer la methode 
getActiveJobsO a la classe JobeetCategory. 

Detail de la methode getActiveJobsO du fichier lib/model/doctrine/ 
JobeetCategory.class.php 

public function getActiveJobsO 
{ 

$q = Doctrine_Query: :create() 
->from(' JobeetJob j') 

->where(' j .category_id = ?', $thi s->getld()) ; 
return Doctrine: :getTable(' JobeetJob')->getActiveJobs($q) ; 

} 

La methode JobeetCategory: :getActiveJobs() se sert de la methode 
Doctrine: :getTable(' JobeetJob')->getActiveJobsO pour retrouver les 
offres d'emploi actives pour la categorie donnee. 

Le but, en faisant appel a Doctrine: :getTable(' JobeetJob') 
->getActi veJobs () , est de preciser la condition en fournissant une categorie. 

Un objet Doctri ne_Query est passe a la place d'un objet JobeetCategory, 
c'est la en effet la meilleure maniere d'encapsuler une condition generique. 

La methode getActiveJobsO a besoin de fusionner cet objet 
Doctri ne_Query avec sa propre requete. C'est en fait tres simple a realiser 
puisque Doctri ne_Query est lui-meme un objet. 

Detail de la methode getActiveJobsO du fichier lib/model/doctrine/ 
JobeetJobTable.class.php 

public function getActiveJobs(Doctrine_Query $q = null) 
{ 

if (is_null($q)) 
{ 

$q = Doctri ne_Query: :create()->from(' JobeetJob j'); 

} 

$q->andWhere( ' j . expi res_at > ?', date('Y-m-d h:i:s', time())) 
->addOrderBy(' j .expi reseat DESC) ; 

return $q->execute() ; 

} 



Limiter le nombre de resultats affiches 



II y a un autre besoin fonctionnel a implementer pour la page d'accueil 
de listage des offres d'emploi : 



« Pour chaque categorie, la liste montre seulement les 10 premieres offres 
d'emploi et un lien permet de lister toutes les offres de cette derniere ». 

C'est aussi simple que d'ajouter une methode getActi veJobsQ : 



Methode getActi velobs() du fichier lib/model/doctrine/JobeetCategory.class.php 

public function getActi veJobs($max = 10) 

{ 

$q = Doctrine_Query: :create() 
->f rom( ' JobeetJob j') 

->where( ' j . category_i d = ?', $thi s->getld()) 
->1 imit($max) ; 

return Doctrine: :getTable(' JobeetJob')->getActiveJobs($q) ; 

} 

La clause LIMIT appropriee est pour l'instant codee en dur a l'interieur 
du modele. Or, il serait plus pertinent de rendre cette valeur configu- 
rable, comme nous l'avons vu plus haut dans ce chapitre. Pour ce faire, il 
suffit de changer le template afin de passer un nombre maximum 
d'offres d'emploi defini dans le fichier app.yml. 
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Figure 6-2 

Classement des offres d'emploi par categorie 
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■a 

Code a remplacer dans le fichier apps/frontend/modules/job/indexSuccess.php 5 

.Si 

<?php foreach (Scategory- ^ 
>getActiveJobs(sfConfig: :get('app_max_jobs_on_homepage')) as $i s 
=> $job): ?> | 

© 

1 

Puis, le nouveau parametre doit etre ajoute au fichier app . yml : '1 

'•s. 
o 

all : i 
active_days: 30 "° 

max_jobs_on_homepage: 10 



Modifier les donnees de test 
dynamiquement par I'ajout de code PHP 

Mis a part reduire le parametre max_jobs_on_homepage a 1, on ne distin- 
guera aucune difference. II est done necessaire d'aj outer un ensemble 
d'offres d'emploi aux donnees de test. Bien sur, il est tout a fait possible 
de copier et coller une offre existante dix ou vingt fois a la main. . . mais il 
existe une bien meilleure facon de faire. La duplication est a eviter, 
meme dans les fichiers de donnees. 

Heureusement, les fichiers YAML de Symfony peuvent contenir du 
code PHP qui sera evalue juste avant l'analyse du fichier, comme le 
montre le fichier de donnees jobs. yml modifie : 

DobeetJob: 

# Starts at the beginning of the line (no whitespace before) 
<?php for ($i = 100; $i <= 130; $i++): ?> 
job_<?php echo $i ?>: 

JobeetCategory : programming 

company: Company <?php echo $i."\n" ?> 

position: Web Developer 

location: Paris, France 

description: Lorem ipsum dolor sit amet, consectetur 

adipisicing elit. 
how_to_apply : | 

Send your resume to lorem. ipsum [at] company_<?php echo $i ?>.sit 
is_public: true 
is_activated: true 

token: job_<?php echo $i."\n" ?> 

emai 1 : j ob@exampl e . com 

<?php endfor; ?> 



Attention Indentation du code YAML 

Attention a ne pas bousculer I'indentation de 
code YAML ! L'interpreteur syntaxique du YAML 
n'aimera pas le developpeur si ce dernier desor- 
donne I'indentation. II faut toujours garder en 
tete les quelques astuces suivantes lorsque Ton 
ajoute du code PHP a un fichier YAML : 

• les instructions <?php ?> doivent toujours 
etre en debut de ligne ou bien etre encapsu- 
lates dans une valeur ; 

• si une instruction <?php ?> termine une 
ligne, une nouvelle ligne (\n) doit explicite- 
ment etre imprimee en sortie. 
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Lors du rechargement des donnees de test avec la tache doctrine: data- 
load, on voit que seules dix offres d'emploi sont affichees sur la page 
d'accueil pour la categorie Programming. Dans la capture d'ecran sui- 
vante, le nombre maximum d'offres d'emploi a ete fixe a cinq pour rea- 
liser une image plus petite. 



Figure 6-3 

Limitation du nombre 
I'offres d'emploi par categorie 
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Empecher la consultation (Tune offre 
expiree 

Lorsqu'une offre d'emploi expire, meme en ayant connaissance de 
FURL, il ne devrait plus etre possible d'y acceder. II suffit d'essayer 
FURL d'une offre expiree (en remplacant Fid par Fid courant dans la 
base de donnees - SELECT id, token FROM jobeet_job WHERE 
expi res_at < N0W()) : 

/f rontend_dev. php/job/sensio-1 abs/pari s-f ranee/ 
ID/web-developer-expired 



Au lieu d'afficher une offre d'emploi, l'application doit rediriger l'utilisa- 
teur vers une page d'erreur 404. Or comment realiser cela, sachant 
qu'une offre est automatiquement retrouvee par sa route ? 

Definition de la route job_show_user dans le fichier apps/frontend/config/ 
routing.yml 

job_show_user : 

url : /job/:company_slug/:location_slug/:id/ :position_slug 
class: sfDoctri neRoute 
options : 

model : DobeetJob 

type: object 

method_for query : retrieveActiveJob 

param: { module: job, action: show } 
requi rements : 
id: \d+ 

sf_method: [GET] 



Remarque 

A propos des versions de Symfony 

Le parametre method_for_query ne fonc- 
tionne pas pour les versions anterieures a 
Symfony 1.2.2. 



a. 
O 



404 | Not Found | sfError404Exception 




Unable to find the JobeeUobPeer object with the following parameters "array ( 
'company_slug' > 'sensio-labs', 'location_slug' => pa ris-f ranee', 'id 1 > '8', 
positionslug' => 'web-developer-expired',)"). 

stack trace 

1. at() 

in SF ROOT DIR/lib/vendor/symfony/lib/routing/sfObjectRoute.dass.php line 111 

108. // check the related object 

109. if ( I (Sthis->object - Sthia->getObjectForParair«ters( Sthia->parametera) ) 6& ( 1 iaaet ($thia->0] 

110. ( 

111. throw new af Brror404Bxceptioo( aprintff 'Unable to find the %a object with the following pa: 

112. } 
113. 

114. return Sthia->object; 

2. at sfObjectRoute->getObject() 

in SF_ROOT DIR/apps/frontend/modules/job/actions/adions.dass.php line 20 ~. 

3. at jobActions->executeShow(object('sfWebRequesf)) 

in SF_ROOT_DIR/lib/vendor/symfony/lib/adion/sfAdions.dass.php line 53 ^ 

4. at sfActions->execute(ofcyect{'sfWebRequest')) 

in SF_ROOT_DlR/lib/vendor/symfony/lib/Filter/sfExecutionFilter.dass.php line 90 ^ 

5. at sfExecutionFilter->executeAction(o£y'ect('jobActions')) 

in SFROOTDIR/lib/vendor/symfony/lib/Filter/sfExecutionFilter.dass.php line 76 „. 

6. at sfExecutionFilter->handleAclion(ob;ect('sfFilterChain'), o£>/ect('jobActions')) 
in SF_ROOT DJR/lib/vendor/symfony/lib/fttter/sfExecutionFilter.dass.php line 42 ^ 

7. at sfExecutionFilter->execute(ofcyecf('sfFilterChain')) 

in SF_ROOT_DlR/lib/vendor/symfony/lib/Filter/sfFilterChain.dass.php line 53 ^ 

8. at sfFilterChain->execute() 

in SF_ROOT_DlR/lib/vendor/symfony/lib/filter/sfCommonFilter.dass.php line 29 ^ 

9. at sfCommonFilter->execute{o£>7ect('sfFilterChain')) 

in SF_ROOT_DlR/lib/vendor/symfony/lib/Ftlter/sfFilterChain.dass.php line 53 „. 

10. at sfFilterChoin->execute() 

in SF_ROOT_DlR/lib/vendor/symfony/lib/filter/sfRenderingFitter.dass.php line 33 ^ 

Figure 6-4 Page d'erreur 404 d'une offre d'emploi expiree 
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La methode retrieveActi veJob() recevra l'objet Doctn'ne_Query cons- 
truit par la route : 

Contenu du fichier lib/model/doctrine/JobeetJobTable.class.php 

class JobeetJobTable extends Doctri ne_Tabl e 
{ 

public function retrieveActiveDob(Doctrine Query $q) 
{ 

$q->andWhere(' a. expires at > ?', date( ' Y-m-d h:i:s', 
timeO)); 

return $q->fetchOne() ; 

} 

// ... 

} 

Desormais, l'utilisateur qui tente d'acceder a une offre expiree est auto- 
matiquement redirige vers une page d'erreur 404. 



freer une page dediee a la categoric 

A present, il serait pratique de disposer d'une page n'affichant que les 
offres d'une certaine categorie (passee en parametre), ainsi qu'un lien 
pour y acceder via la page d'accueil. 

Mais attendez ! Arretons la ce sixieme chapitre - meme si nous n'avons 
pas tant travaille - car vous avez suffisamment de connaissances pour 
implementer vous-meme cette fonctionnalite en guise d'exercice. La 
correction sera presentee au chapitre suivant. . . 



En resume... 

Ce chapitre a aborde plus en detail ce qu'il est possible de realiser a partir 
du modele de donnees du framework Symfony. N'hesitez pas a travailler 
sur votre copie de travail locale de Jobeet ainsi qua utiliser la documenta- 
tion de 1API en ligne, disponible sur le site officiel de Symfony a 
l'adresse http://www.symfony-project.org/api/1_2/. Limplementation de la 
page de detail d'une categorie sera, quant a elle, devoilee tout au long du 
chapitre suivant. 
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Concevoir et paginer la liste 
d'offres d'une categorie 



Les chapitres precedents ont montre toute l'importance 
du motif MVC et de l'interet de ne pas dupliquer le code 
dans un projet web. Le framework Symfony recele encore 
bien d'autres outils pour satisfaire ce besoin dans la vue, 
notamment grace aux templates partiels qui seront decrits 
dans ce septieme chapitre. 



MOTS-CLES : 

► Routage 

► Templates partiels 

► Pagination 



Au cours du chapitre precedent, il a ete montre que Symfony excelle 
dans differents domaines : les requetes SQL avec Doctrine, les donnees 
de test, le routage, le debogage ainsi que la configuration sur mesure. Le 
dernier chapitre se cloturait sur un petit defi : mettre en place une « page 
dediee a la categorie ». Dans celui-ci, le but est de donner une solution a 
ce probleme, en commencant par la presentation d'une potentielle 
implementation. 

Mise en place d'une route dediee a la page 
de la categorie 

Declarer la route category dans le fichier routing.yml 

La premiere etape avant de demarrer l'implementation de cette nouvelle 
page consiste a etablir une nouvelle route propre a la categorie. Dans la 
mesure ou la categorie est un objet Doctrine, le choix de la classe 
sfDoctrineRoute pour gerer la route dediee en decoule naturellement. 
Le code ci-dessous a ajouter au fichier de configuration routing.yml 
decrit la route propre a chaque categorie. 

Route a ajouter au debut du fichier apps/frontend/config/routing.yml 

category: 

url : /category/: slug 

class: sfDoctrineRoute 

param: { module: category, action: show } 

options: { model: JobeetCategory , type: object } 

Une route peut utiliser n'importe quelle colonne de son objet relatif en tant 
que parametre. Elle peut egalement avoir recours a n'importe quelle autre 
valeur du moment qu'il existe un accesseur associe dans la classe de l'objet. 

Implementer I'accesseur getSlugO dans la classe 
JobeeUob 

Du fait que le parametre slug ne dispose d'aucune correspondance dans 
la table des categories, la classe JobeetCategory doit se voir completee 
d'un accesseur virtuel afin de rendre la route fonctionnelle. 



Methode getSlugQ a ajouter au fichier lib/model/doctrine/JobeetCategory.class.php 



Personnaliser les conditions d'affichage du 
lien de la page de categoric 

Integrer un lien pour chaque categorie ayant plus de dix 
offres valides 



Pour l'instant, la page d'accueil de Jobeet ne dispose d'aucun lien pour se 
rendre directement sur la page de detail d'une categorie. La page 
d'accueil est l'endroit opportun pour faire figurer un lien vers le detail de 
chaque categorie listee. Neanmoins, pour ne pas surcharger inutilement 
cette page, seules les categories ayant plus de dix offres d'emploi actives 
se verront ajouter un lien. Pour ce faire, le fichier i ndexSuccess . php du 
module job doit etre modifie pour accueillir ce nouveau lien comme le 
montre le code ci-dessous. 

<! — some HTML code --> 

<hl> 

<?php echo link to($category, 'category', $category) ?> 

</hl> 

<! — some HTML code --> 



<?php if (($count = $category->countActiveJobs() - 
sfConfig: :get('app max jobs on homepage')) > 0) : ?> 

<div cl ass="more_jobs"> 

and <?php echo link to($count, 'category', $category) ?> 
more . . . 
</di v> 
<?php endif; ?> 
</di v> 
<?php endforeach; ?> 
</di v> 



public function getSlugO 
{ 



Methode Implementation 
d'une nouvelle fonctionnalite 



return Dobeet: :s1ugify($this->getName()) ; 

} 



Lorsque Ton demarre 1'implementation d'une nou- 
velle fonctionnalite, une bonne pratique consiste, 
dans un premier temps, a penser a I'URL, puis a 
creer la route associee. C'est d'ailleurs obligatoire 
quand les routes par defaut ont ete supprimees. 



</tab1e> 
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Le lien sera ajoute a la page seulement s'il y a plus de 10 offres d'emploi 
a afficher pour la categorie courante. Le lien contient le nombre d'offres 
non affichees. Afin que ce template puisse se comporter de la sorte, la 
methode countActiveJobsO doit etre implementee dans la classe 
JobeetCategory. 

Implementer la methode countActiveJobsO de la classe 
JobeetCategory 

Le template indexSuccess.php du module job fait appel a la methode 
countActiveJobsO de l'objet de la categorie courante. Pour l'instant, cette 
methode n'existe pas encore dans la classe JobeetCategory. Elle sert a 
compter le nombre d'offres d'emploi actives a l'instant t pour la categorie. 
Le code ci-apres donne le detail complet de cette nouvelle methode. 

Methode countActiveJobsO a ajouter au fichier lib/model/doctrine/ 
JobeetCategory.class.php 

public function countActiveJobsO 
{ 

$q = Doctrine_Query: :create() 
->f rom( ' JobeetJob j') 

->where(' j . category^i d = ?', $thi s->getld()) ; 
return Doctrine: :getTable(' JobeetJob')->countActiveJobs($q) ; 

} 

Implementer la methode countActiveJobsO de la classe 
JobeetCategoryTable 

La methode countActiveJobsO fait appel a une autre methode 
countActiveJobsO, qui elle non plus n'existe pas dans la classe 
JobeetJobTable. Cette nouvelle methode doit etre capable de prendre un 
objet Doctri ne_Query en argument afin de retourner le nombre d'offres 
d'emploi valides qui correspondent aux criteres de cette requete. II faut pour 
cela remplacer le code de Jobeet JobTabl e . cl ass . php par le code suivant : 

Contenu du fichier lib/model/doctrine/JobeetJobTable.class.php 

] class JobeetJobTable extends Doctri ne_Tabl e 
{ 

public function retrieveActiveJob(Doctrine_Query $q) 
{ 

return $this->addActiveJobsQuery($q)->fetchOne() ; 

} 



public function getActiveJobs(Doctrine_Query $q = null) 
return $thi s->addActivelobsQuery($q)->execute() ; 

public function countActiveJobs(Doctrine Query $q = null) 
return $this->addActiveJobsQuery($q)->count() ; 

public function addActiveJobsQuery(Doctrine Query $q = null) 

if (is null ($q)) 
{ 

$q = Doctrine Query: :create() 
->from(' JobeetJob j'); 

} 

$alias = $q->getRootAl ias() ; 

$q->andWhere($al ias . '.expires_at > ?', 
date('Y-m-d h:i:s', time())) 
->addOrderBy($alias . '.expires at DESC); 

return $q; 

} 

} 

Le code de la classe JobeetJobTable a ete factorise afin d'introduire une 
nouvelle methode partagee addActiveJobsQueryO et de rendre ainsi le 
code plus DRY (Don't Repeat Yourself). 

La methode countActi veJobsO utilise directement la methode count () 
plutot que la methode execute () suivie d'un comptage manuel des 
resultats, et ce pour des raisons evidentes de performance. En effet, 
recourir directement a la methode count () evite la creation et l'hydrata- 
tion d'objets en memoire ; seule la valeur resultante du denombrement 
est renvoyee. 

Plusieurs fichiers ont du etre modifies dans le but d'implementer cette 
nouvelle fonctionnalite. Cependant, le code ecrit a systematiquement ete 
place dans la couche adequate de 1' application, notamment pour le 
rendre reutilisable ulterieurement. Tout au long du processus, des pieces 
de code existant ont ete factorisees. Ce type de processus de travail est 
typique des projets et de la philosophic du framework Symfony. 



Bonne pratique La refactorisation de code 

La premiere fois qu'un bout de code est reuti- 
lise, le copier peut paraitre suffisant. Or, si on lui 
trouve un nouvel usage, cela implique qu'il faut 
refactoriser tous ces emplois dans une meme 
fonction ou methode partagee, comme il I'a ete 
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Mise en place du module dedie aux 
categories 

Generer automatiquement le squelette du module 

L'application Jobeet doit se doter d'un nouveau module destine a 
accueillir les specificites des categories. II est bien stir tentant de recourir 
a la tache doctri ne:generate-crud afin de construire un module com- 
plet de la meme maniere que pour le module job. Neanmoins, pres de 
90 % du code genere aurait ete jete au rebut. Pour cette raison, la crea- 
tion d'un module basique entierement vide est realisee au moyen de la 
tache generate: module. 

$ php symfony generate: module frontend category 
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En accedant a la page d'une categorie, la route de celle-ci doit trouver 
l'objet JobCategory associe a l'aide de la variable slug de la requete. Or, 
le slug n'est pas stocke dans la base de donnees, ce qui rend done impos- 
sible la deduction d'une categorie a partir du slug. 

Ajouter un champ supplemental pour accueillir le slug 
de la categorie 

Afin de pouvoir identifier de maniere unique une categorie a partir d'un 
slug, la presence d'un champ slug dans la table jobeet_category est 
necessaire. Grace aux nombreux outils internes livres avec Doctrine, la 
generation d'un slug a partir de la valeur d'un autre champ de la table 
SQL est entierement automatisee. Pour ce faire, il suffit d'activer le 
comportement Sluggable pour le modele JobeetCategory dans le 
schema de description de la base de donnees. 

Activation du comportement Sluggable dans le fichier config/doctrine/schema.yml 

JobeetCategory : 
actAs : 

Timestampable: ~ 
Sluggable: 

fields: [name] 
columns: 
name : 

type: string(255) 
notnul 1 : true 

A present, la generation d'un slug unique a partir de la valeur du champ 
name est automatiquement geree par Doctrine. De ce fait, la methode 
getSlugO de la classe JobeetCategory ha plus raison d'exister et conduit 
done a son retrait. Pour finaliser la mise en place du slug, l'ensemble du 
modele ainsi que la base de donnees doivent etre reconstruits a l'aide de la 
tache doctrine: build-all -reload. Au chargement des donnees initiales 
de test, le champ si ug se verra automatiquement renseigne par Doctrine. 

| $ php symfony doctrine:build-all-reload — no-confirmation 

Creation de la vue de detail de la categorie 
Mise en place de faction executeShow() 

La route category declaree plus haut dans le fichier de configuration 
routing. yml s'appuie sur Taction show du module category. Pour l'ins- 
tant, la methode executeShowO ne figure pas dans la classe des actions 
du module. Le corps de cette methode se resume a une seule et unique 



Choix de conception Creer un nouveau 
module category dedie ou ajouter 
une action au module job ? 

Pourquoi ne pas ajouter une action category au 
module job? C'est en fait parce que le sujet prin- 
cipal est la categorie elle-meme. Pour cette raison, 
il semble plus naturel et logique de creer un 
module category dedie. II y a en effet plus de 
sens a considerer la liste des categories comme 
une entite a part entiere, plutot que comme une 
petite partie d'un module deja existant. Savoir 
donner du sens a la conception generale de Impli- 
cation et au code ecrit n'est pas chose facile mais 
se revele particulierement important. 
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ligne de code qui a deja ete etudiee precedemment dans cet ouvrage. II 
s'agit en effet de recuperer l'objet DobeetCategory a partir de sa route. Le 
code ci-dessous presente le contenu du fichier actions.class.php du 
module. 

Contenu du fichier apps/frontend/modules/category/actions/actions.class.php 

class categoryActions extends sf Actions 
{ 

public function executeShow(sfWebRequest Srequest) 
{ 

$this->category = $this->getRoute()->get0bjectO ; 

} 

} 

La methode index() generee par defaut lors de la creation du module a 
ete volontairement supprimee du fichier car elle ne sera pas utilisee dans 
la suite du developpement. De ce fait, son template associe 
i ndexSuccess . php peut a son tour etre retire du projet. Apres la mise en 
oeuvre de Faction executeShow(), il ne reste plus qua ecrire le template 
correspondant showSuccess.php. 

Integration du template showSuccess.php associe 

La finalisation de la nouvelle page de detail de la categorie requiert evi- 
demment l'ecriture d'un fichier de template showSuccess.php. Ce der- 
nier reutilise tel quel le tableau HTML du template i ndexSuccess. php 
du module job pour afficher la liste des offres d'emploi actives. 

Contenu du fichier apps/frontend/modules/category/templates/showSuccess.php 

<?php use_stylesheet(' jobs. ess') ?> 

<?php slot ('title' , sprintf('Dobs in the %s category', 
$category->getName())) ?> 

<div cl ass="category"> 
<div c1ass="feed"> 

<a href="">Feed</a> 
</di v> 

<hlx?php echo Scategory ?></hl> 
</di v> 

<table c1ass="jobs"> 

<?php foreach ($category->getActive3obs() as $i => $job): ?> 
<tr class="<?php echo fmod($i, 2) ? 'even' : 'odd' ?>"> 
<td class="1ocation"> 

<?php echo $job->getLocation() ?> 
</td> 



<td c1ass="position"> 
<?php echo 1 ink to($job->getPosition() , 'job show user' , 
$job) ?> 

</td> 

<td c1ass="company"> 

<?php echo $job->getCompany() ?> 

</td> 
</tr> 

<?php endforeach; ?> 

</tab1e> 

Bien qu'il soit entierement fonctionnel, ce fichier dispose d'un inconvenient 
majeur : il duplique le code du template i ndexSuccess . php du module job. 
La philosophic du framework Symfony favorise autant que possible la 
separation du code en plusieurs couches distinctes grace au modele MVC, 
mais aussi l'isolement du code dans le but d'eviter la duplication. 

La duplication de code ne concerne pas seulement le code PHP, elle 
impacte egalement le code HTML, ce qui complexifie davantage les 
developpements et la maintenance de l'application. La section suivante 
presente quelle solution technique le framework Symfony met en oeuvre 
pour favoriser la factorisation et l'isolement du code HTML. 

Isoler le HTML redondant dans les templates partiels 
Decouvrir le principe de templates partiels 

Le template PHP showSuccess.php du module category copie l'integra- 
lite de la balise <table> generant la liste d'offres d'emploi du fichier 
i ndexSuccess. php. Bien entendu, cette duplication du code va a 
l'encontre des principes fondamentaux et des bonnes pratiques defendus 
jusqu'a maintenant. II est done temps d'apprendre comment remedier a 
cette problematique. 

Lorsqu'une petite partie d'un template a besoin d'etre dupliquee pour 
etre reutilisee ailleurs dans un autre, e'est le signe qu'il faut l'isoler dans 
un fichier a part. Dans Symfony, on park de creer un template partiel 
(fax. partial). Un partiel est un fragment de code d'un template qui a pour 
objectif d'etre partage par plusieurs autres templates. D'un point de vue 
technique, il s'agit en realite de creer un fichier PHP dont le nom debute 
par un tiret souligne (ou underscore, caractere _) et de l'enregistrer dans 
les repertoires templates/ du projet. 



Creation d'un template partiel Jist.php pour les modules job 
et category 

L'explication precedente a introduit la notion de templates partiels. 
Comment cela se presente-t-il plus concretement dans un projet 
Symfony ? Comme il l'a ete demontre juste avant, la generation de la 
liste des offres d'emploi d'une categorie dans les templates 
showSuccess . php et i ndexSuccess . php est strictement identique. Le code 
duplique doit done etre isole dans un template partiel _list.php du 
module job comme le montre le code ci-dessous. 

Contenu du fichier apps/frontend/modules/job/templates/Jist.php 

<table dass="jobs"> 

<?php foreach ($jobs as $i => $job): ?> 

<tr class="<?php echo fmod($i , 2) ? 'even' : 'odd' ?>"> 
<td class="1ocation"> 

<?php echo $job->getl_ocationO ?> 
</td> 

<td class="position"> 

<?php echo link_to($job->getPosition() , ' job_show_user ' , 
$job) ?> 

</td> 

<td cl ass="company"> 

<?php echo $job->getCompany() ?> 
</td> 
</tr> 

<?php endforeach; ?> 
</tab1e> 

Faire appel au partiel dans un template 

L'utilisation d'un template partiel dans un template traditionnel est rea- 
lised au moyen du helper Symfony include_partia1 (). Cette fonction 
accepte deux parametres. Le premier est le nom du partiel a appeler. II 
s'agit d'une chaine de caracteres qui se compose du nom du module dans 
lequel se trouve le partiel, puis d'une barre oblique / et enfin du nom du 
partiel auquel le tiret souligne de debut est omis. Le second argument de 
include_partia~l O est un tableau associatif des variables a transmettre 
au partiel. Les cles du tableau correspondent au nom des variables du 
partiel, et les valeurs sont les variables a transmettre au partiel. Un bon 
exemple valant mieux qu'un long discours, le code ci-dessous resume le 
fonctionnement du helper include_partial (). 

| <?php include_partial ('job/list' , arrayC jobs' => Sjobs)) ?> 

Les developpeurs familiers du langage PHP se demandent certainement 
quelle est la veritable difference entre le helper i ncl ude_parti al () et un 
simple appel a i ncl ude() ou requi re(). Le premier avantage concerne le 



nommage des variables transmises au partiel. En effet, il nest pas neces- 
saire que ces dernieres aient le meme nom que celles du partiel. C'est le 
tableau associatif passe en second argument qui se charge de faire la cor- 
respondance. D'autre part, le helper inc"lude_partia"l () a l'avantage de 
pouvoir mettre en cache le template partiel qu'il appelle. 

Utiliser le partiel Jist.php dans les templates indexSuccess.php 
et showSuccess.php 

Le template partiel _list.php est pret et n'attend qua etre implemente 
dans un template. De 1' autre cote, les vues showSuccess.php et 
indexSuccess.php des modules category et job n'attendent qua etre 
simplifiees grace a ce dernier. Les bouts de code ci-dessous sont les 
appels au partiel a integrer aux vues PHP precedentes a la place du code 
PHP qui genere la liste des offres d'emploi. 

Code a ajouter au fichier apps/frontend/modules/job/templates/indexSuccess.php 

<?php inc"lude_partia"l ('job/list' , array (' jobs' => $category 
->getActi vej obs (sf Conf i g : : get ( ' app_max_j obs_on_homepage ' ) ) ) ) ?> 

Code a ajouter au fichier apps/frontend/modules/category/templates/ 
showSuccess.php 

<?php includejartial (' job/list' , arrayC jobs' => Scategory 
->getActive3obs())) ?> 



Paginer une liste d'objets Doctrine 

Plus le site evolue, plus il grandit et plus son contenu s'enrichit. C'est 
d'autant plus vrai lorsque ce sont les utilisateurs eux-memes qui sont a la 
source de ce dernier. Pour cette raison, l'integralite du contenu editorial 
doit etre clairement organisee dans le but de faciliter la navigation et 
1' experience utilisateur. Cela debute naturellement par la pagination des 
listes de resultats recuperes de la base de donnees. Cette section explique 
pas a pas le processus de creation d'une liste paginee d'offres d'emploi 
pour chaque categoric 

Que sont les listes paginees et a quoi servent-elles ? 

Paginer une liste d'objets en provenance d'une base de donnees est une 
tache recurrente dans les projets informatiques. Les listes paginees ser- 
vent par exemple a alleger le flux d'informations qui transitent sur le 
reseau, a optimiser le nombre de donnees affichees simultanement sur 



l'ecran de l'utilisateur, ou bien encore a reduire les temps de chargement 
des pages... En somme, elles ameliorent le confort d'utilisation et 
l'experience utilisateur. 

Bien que ces listes soient courantes, elles n'en demeurent pas moins 
complexes et fastidieuses a mettre en ceuvre car elles necessitent le fran- 
chissement de plusieurs etapes successives, telles que la determination de 
la page courante, le calcul du debut de la position du curseur dans la liste 
de resultats, le comptage des objets a recuperer, la recuperation des don- 
nees, l'affichage des liens de pagination... 

Preparer la pagination a I'aide de sfDoctrinePager 

Heureusement, Symfony integre un composant natif oriente objet qui 
facilite considerablement la creation de listes paginees de resultats issus 
d'une base de donnees. II s'agit de 1' objet sfDoctrinePager qui a pour 
role de gerer dynamiquement la pagination d'une liste d'objets Doctrine. 
L'action show du module category est particulierement concernee par la 
mise en ceuvre d'un tel mecanisme dans la mesure ou le nombre d'offres 
d'emploi publiees risque de croitre a vive allure. 

Initialiser la classe de modele et le nombre maximum d'objets 
par page 

Pour eviter de saturer inutilement la page et faire fuir l'utilisateur, la liste 
des offres doit etre paginee, et des liens en bas de page doivent permettre 
de naviguer dans les offres de maniere antechronologique. Le code ci- 
dessous detaille la marche a suivre pour configurer la pagination d'une 
liste d'objets Doctrine a I'aide du composant sfDoctrinePager. 

Definition d'un objet sfDoctrinePager dans apps/frontend/modules/category/ 
actions/actions.class.php 

public function executeShow(sfwebRequest Srequest) 
{ 

$this->category = $this->getRoute()->getObject() ; 

$this->pager = new sfDoctrinePager( 
'JobeetDob' , 

sf Conf i g : : get ( ' app max jobs on category ' ) 

); 

$this->pager->setQuery($this->category 

->getActiveDobsQuery()) ; 
$this->pager->setPage($request->getParameter( , page' , 1)); 
$this->pager->init() ; 

} 



Le constructeur de la classe sfDoctri nePager accepte deux arguments. 
Le premier est le nom de la classe modele des objets a recuperer. Dans le 
cas present, il s'agit de la classe JobeetJob. Le second est le nombre 
maximum d'objets presents sur chaque page. 

Pour des raisons evidentes de personnalisation ulterieure, cette valeur est 
stockee dans une constante de configuration du fichier app.yml. II sera 
ainsi plus aise d'ajuster le nombre maximum d'objets par page si besoin. 

Contenu du fichier apps/frontend/config/app.yml 

all : 

active_days: 30 
max_jobs_on_homepage: 10 
max_jobs_on_category : 20 

Specifier I'objet Doctrine_Query de selection des resultats 

Par ailleurs, la methode setQueryO de I'objet sfDoctri nePager recoit en 
parametre un objet de type Doctrine_Query. Celui-ci correspond effecti- 
vement a la requete SQL a executer pour rapatrier la liste d'objets Doc- 
trine de la base de donnees. 

Passer une Doctrine_Query en argument permet ainsi d'obtenir la liberte 
de creer des requetes aussi bien simples que complexes. C'est la l'une des 
forces et toute la souplesse de FORM Doctrine. Dans le cas present, 
I'objet Doctri ne_Query est issu de la methode getActi veJobsQueryO de 
la classe DobeetCategory. Cette methode est implemented quelques 
lignes plus bas. 

Configurer le numero de la page courante de resultats 

Enfm, I'objet sfDoctri nePager a besoin de connaitre le numero de la page 
courante afin de determiner quels enregistrements il doit recuperer et com- 
bien il y a de pages au total. La methode setPageO accepte comme seul et 
unique argument le numero de la page courante. II est ici fourni a l'aide de 
la methode getParameterO de I'objet sf Request. Dans le cas present, le 
numero de la page en cours est transmis par l'URL dans la variable page. 
Le second argument de la methode getParameterO correspond a la valeur 
par defaut a retourner si la variable page n'existe pas ou est nulle. 

Initialiser le composant de pagination 

Enfin, la methode i ni t() de I'objet sfDoctri nePager se charge d'initialiser 
la liste paginee. A ce stade, elle calcule le nombre de pages total, la position 
du curseur dans la liste ainsi que le nombre exact de resultats a paginer. 



Simplifier les methodes de selection des resultats 



Implementer la methode getActiveJobsQuery de I'objet 
JobeetCategory 

Comme il l'a ete decrit plus haut, le fonctionnement de I'objet 
sfDoctrinePager repose sur 1'utilisation d'un objet de type 
Doctrine_Query pour effectuer le comptage du nombre total de resultats, 
ainsi que pour selectionner les vingt objets par page. Pour l'instant, la 
methode getActi veJobsQueryO de la classe JobeetCategory reste a 
implementer. Cette derniere retourne la requete de selection de toutes 
les offres actives de la categorie courante triees par ordre antechronolo- 
gique suivant leur date d'expiration. Le code ci-dessous detaille l'imple- 
mentation de cette methode. 

Methode getActiveJobsQueryO du fichier lib/model/doctrine/ 
JobeetCategory.class.php 

public function getActiveJobsQueryO 
{ 

$q = Doctrine_Query: :create() 
->from(' JobeetJob j') 

->where(' j . category^i d = ?', $thi s->getld()) ; 

return Doctrine: : getTabl e( ' JobeetJob ' ) 
->addActiveJobsQuery($q) ; 

} 

Remanier les methodes existantes de JobeetCategory 

Maintenant que la methode getActiveJobsQueryO est clairement definie, 
on peut se poser la question de savoir dans quelle mesure elle peut etre reuti- 
lisee par d'autres methodes de la classe. En effet, la requete SQL representee 
par I'objet Doctrine_Query quelle renvoie est suffisamment generique et 
surtout commune aux methodes getActi veJobsO et countActi veJobsO 
pour qu'il soit interessant de proceder a un leger remaniement du code de 
ces dernieres, afin de les simplifier en faisant en sorte qu'elles implementent 
cette nouvelle methode. A present, les deux methodes getActi ve Jobs () et 
countActi ve Jobs O se resument au code ci-apres. 



Refactorisation de methodes dans le fichier lib/model/doctrine/JobeetCategory.class.php 

public function getActiveJobs($max = 10) 
{ 

retu rn $thi s->getActi veJobsQuery () ->1 i mi t ($max) ->execute () ; 

} 

public function countActiveJobs() 
{ 

return $thi s->getActive3obsQuery()->count() ; 

} 

La derniere etape necessaire a la fmalisation de la pagination de la liste des 
offres d'emploi de la categorie courante est bien evidemment Fintegration 
des liens de navigation a Finterieur du template showSuccess.php. La 
partie suivante explique tout cela avant de cloturer ce chapitre. 

Integrer les elements de pagination dans le template 
showSuccess.php 

Le template showSuccess.php doit implementer plusieurs elements afin 
d'etre complet. Les lignes qui suivent expliquent pas a pas les morceaux 
de code a ajouter ou modifier dans le template pour y parvenir. La pre- 
miere etape consiste a mettre a jour l'appel au partiel _1 i st . php. 

Passer la collection d'objets Doctrine au template partiel 

Tout d'abord, le template showSuccess.php a besoin de mettre a jour 
l'appel au template partiel _1 i st . php car la variable qui lui est transmise 
jusqu'a present n'existe plus. En effet, la vue de Faction show recoit main- 
tenant de la part de Faction la variable $pager qui contient Fensemble de 
la pagination, y compris la collection d'objets Doctrine a passer au tem- 
plate partiel. 

Pour y parvenir, Fobjet sfDoctrinePager integre la methode 
getResultsO qui se charge d'executer la requete SQL de Fobjet 
Doctri ne_Query, puis d'hydrater la collection d'objets JobeetJob avant de 
la stocker dans une propriete privee et enfin de la retourner. Cette 
methode renvoie un objet Doctri ne_Col lection qui est affecte a la cle 
jobs du tableau associatif comme le montre le code ci-dessous. 

Appel au template partiel a remplacer dans le fichier apps/frontend/modules/ 
category/templates/showSuccess.php 

<?php include_partial ('job/list' , 

arrayC'jobs' => $pager->getResu"lts())) ?> 



E 



Afficher les liens de navigation entre les pages 

L'etape suivante consiste a afficher les liens permettant a l'utilisateur de 
naviguer entre les differentes pages de la categorie en cours. Une fois de 
plus, c'est grace au composant sfDoctrinePager et a ses methodes tres 
pratiques que Ton est capable de generer un systeme de navigation com- 
plet sans se poser de questions. 

Le code suivant est a placer tout en bas de la vue show/Success . php. II 
genere un systeme de pagination integrant les liens pour acceder aux 
premiere et derniere pages, aux pages precedents et suivante, ainsi qu'aux 
pages intermediaires en prenant garde a desactiver le lien de la page sur 
laquelle se trouve l'utilisateur. La description de chacune des methodes 
de l'objet de pagination appele, est expliquee plus loin. 

Creation d'un systeme de pagination complet dans le fichier apps/frontend/ 
modules/category/templates/showSuccess.php 

<?php if ($pager->haveToPaginateO) : ?> 

<div class="pagination"> 

<a href="<?php echo url_for('category' , Scategory) ?>?page=l"> 
<img src="/images/fi rst.png" alt="First page" /> 

</a> 

<a href="<?php echo url_for('category' , Scategory) ?>?page= 
<?php echo $pager->getPreviousPage() ?>"> 
<img src="/images/previous.png" alt="Previous page" 
title="Previous page" /> 

</a> 

<?php foreach ($pager->getLinks() as $page) : ?> 
<?php if ($page == $pager->getPage()) : ?> 

<?php echo $page ?> 
<?php else: ?> 

<a href="<?php echo url_for( ' category ' , Scategory) ?>?page= 
^» <?php echo $page ?>"><?php echo Spage ?></a> 
<?php endif; ?> 
<?php endforeach; ?> 

<a href="<?php echo url_for(' category' , Scategory) ?>?page= 
<?php echo $pager->getNextPage() ?>"> 
<img src="/images/next.png" alt="Next page" 
title="Next page" /> 

</a> 

<a href="<?php echo ur"l_for(' category' , Scategory) ?>?page= 
<?php echo $pager->getLastPage() ?>"> 
<img src="/images/last.png" alt="Last page" 
title="Last page" /> 

</a> 
</di v> 
<?php endif; ?> 
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Afficher le nombre total d'offres publiees et de pages 

Enfin, l'ideal est d'informer l'utilisateur du nombre total d'offres 
d'emploi publiees dans la categorie courante ainsi que le nombre 
maximum de pages qu'il est en mesure de parcourir. Un petit indicateur 
supplemental lui permet de savoir a tout moment sur quelle page il se 
trouve par rapport aux autres comme le montre le bout de code ci-des- 
sous a placer en bas du template. 

Indicateurs du nombre total de resultats et de pages dans le fichier apps/frontend/ 
modules/category/templates/showSuccess.php 

<di v cl ass="pagi nati on_desc"> 

<strongx?php echo $pager->getNbResul ts() ?></strong> jobs in 
this category 

<?php if ($pager->haveToPaginate()) : ?> 

- page <strongx?php echo $pager->getPage() ?>/<?php echo 
$pager->getLastPage() ?></strong> 
<?php endif; ?> 

</di v> 

Description des methodes de I'objet sfDoctrinePager utilisees 
dans le template 

L'objet sfDoctrinePager fournit un certain nombre de methodes particu- 
lierement utiles pour retrouver des informations sur l'etat de la pagination. 
Cela va du numero de la page courante au nombre total de resultats, en pas- 
sant par les numeros des pages suivantes et precedentes. Toutes les 
methodes listees et decrites ci-dessous figurent dans le template 
show/Success . php et ont permis l'elaboration de la pagination de ce dernier. 

• getResul ts () : retourne une collection d'objets Doctrine pour la page 
courante ; 

• getNbResultsO : retourne le nombre total de resultats ; 

• haveToPagi nate() : retourne vrai s'il y a plus qu'une page ; 

• getLinksO : retourne la liste des liens des pages a afficher ; 

• getPageO : retourne le numero de la page courante ; 

• getPreviousPageO : retourne le numero de la page precedents ; 

• getNextPageO : retourne le numero de la page suivante ; 

• getLastPageQ : retourne le numero de la derniere page. 



Code final du template showSuccess.php 

Contenu du fichier apps/frontend/modules/category/templates/showSuccess.php 

i <?php use_styiesheet(' jobs. ess') ?> 

<?php slot ('title' , sprintf(']obs in the %s category', Scategory- 
>getName())) ?> 

<div class="category"> 
<div class="feed"> 

<a href="">Feed</a> 
</di v> 

<hlx?php echo Scategory ?></hl> 
</di v> 

<?php inc"lude_partial (' job/list' , 

arrayCjobs' => $pager->getResu"l ts())) ?> 

<?php if ($pager->haveToPaginate()) : ?> 

<div ciass="pagination"> 

<a href="<?php echo ur"l_for('category' , Scategory) ?>?page=l"> 
<img src="/images/fi rst.png" a"lt="First page" /> 

</a> 

<a href="<?php echo ur"l_for(' category' , $category)?>?page= 
<?php echo $pager->getPreviousPage() ?>"> 
<img src="/images/previous.png" a"lt="Previous page" 
title="Previous page" /> 

</a> 

<?php foreach ($pager->getLinks() as Spage) : ?> 
<?php if ($page == $pager->getPage()) : ?> 

<?php echo Spage ?> 
<?php else: ?> 

<a href="<?php echo ur"l_for('category' , Scategory) ?>?page= 
<?php echo $page ?>"><?php echo $page ?></a> 
<?php endif; ?> 
<?php endforeach; ?> 

<a href="<?php echo url_for('category' , Scategory) ?>?page= 
<?php echo $pager->getNextPage() ?>"> 
<img src="/images/next.png" a"lt="Next page" title="Next page" / 

</a> 

<a href="<?php echo ur"l_for(' category' , Scategory) ?>?page= 
<?php echo $pager->getLastPage() ?>"> 
<img src="/images/last.png" alt="Last page" title="Last page" / 
</a> 
</di v> 
<?php endif; ?> 

<div class="pagination_desc"> 

<strongx?php echo $pager->getNbResu1 ts() ?></strong> jobs in 
this category 



<?php if ($pager->haveToPaginateO) : ?> 

- page <strongx?php echo $pager->getPage() ?>/<?php 
echo $pager->getLastPage() ?></strong> 
<?php endif; ?> 

</div> 
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En resume... 

Si vous aviez travaille sur votre propre implementation et si vous avez res- 
senti que vous n'avez pas appris grand chose apres ces quelques pages, cela 
signifie que vous vous etes progressivement habitue a la philosophic du fra- 
mework Symfony. Le processus d'ajout d'une nouvelle fonctionnalite a un 
site web Symfony reste toujours le meme : songer d'abord aux URLs, creer 
les actions, mettre a jour le modele et enfin ecrire quelques templates. Et, si 
vous pouvez appliquer quelques bonnes pratiques de developpement au pas- 
sage, vous maitriserez tees vite le framework. Le chapitre suivant s'interesse a 
un sujet cle du developpement d'applications web professionnelles, a savoir 
la notion de tests unitaires et fonctionnels automatises. Le prochain chapitre 
se focalise sur les tests unitaires tandis que les tests fonctionnels seront pre- 
sented en detail dans le chapitre 9. . . 



chapitre 




Les tests unitaires 



MOTS-CLES 



Trop souvent negliges, oublies, voire laisses de cote 

faute de temps, les tests unitaires sont pourtant des garants 

de la qualite et de la perennite d'une application web. 

Symfony integre nativement un framework de tests unitaires 
et fonctionnels. Ce huitieme chapitre se consacre 
a la decouverte du premier et a l'ecriture des premiers 
tests automatises de Jobeet. 



► Tests unitaires 

► Framework Lime 

► Couverture de code 



Les deux precedents chapitres ont permis de revoir l'ensemble des fonc- 
tionnalites acquises jusqu'a present, d'en personnaliser certaines mais 
aussi d'en ajouter d'autres. 

Ce chapitre aborde quelque chose de completement different : les tests 
automatises. Dans la mesure ou ce sujet est particulierement large, deux 
chapitres entiers y sont consacres afin de pouvoir couvrir l'essentiel des 
fondamentaux. 

Presentation des types de tests dans 
Symfony 

II existe deux types de tests automatises dans Symfony : les tests uni- 
taires et les tests fonctionnels. 

Les tests unitaires verifient que chaque fonction ou methode fonctionne 
correctement. Chaque test doit etre aussi independant que possible des 
autres. 

En revanche, les tests fonctionnels s'assurent que l'application resultante 
se comporte correctement dans sa globalite. 

Dans un projet Symfony, tous les tests se situent dans le repertoire test/ 
du projet. II contient deux sous-dossiers : un pour les tests unitaires 
(test/unit/) et l'autre pour les tests fonctionnels (test/functional/). 

Ce chapitre n'aborde que les tests unitaires tandis que les tests fonction- 
nels seront presentes au chapitre suivant. 

De la necessite de passer par des tests 
unitaires 

Ecrire des tests unitaires est probablement l'une des bonnes pratiques les 
plus importantes du developpement web a mettre en application. En 
effet, les developpeurs ne sont pas toujours sensibilises a tester leur tra- 
vail. Ainsi, cela permet de soulever plusieurs interrogations : faut-il 
ecrire des tests avant d'implementer une fonctionnalite ? Quels outils 
sont necessaires pour tester efficacement ? Les tests ont-ils besoin de 
couvrir tous les cas possibles ? Comment s' assurer que tout l'ensemble 
du projet est bien teste ? Cependant, la toute premiere question qui se 
pose est generalement beaucoup plus triviale : par ou commencer ? 



Si tester massivement est toujours une bonne pratique, l'approche de 
Symfony n'en demeure pas moins pragmatique : il est en effet preferable 
d'avoir seulement quelques tests sous la main plutot que rien du tout. . . 
Le projet a-t-il deja beaucoup de code non teste ? II nest pas necessaire 
d'avoir une suite complete de tests pour profiter des avantages des tests 
automatises. Dans un premier temps, il est bon de commencer par 
ajouter des tests a chaque fois qu'un bogue est decouvert. Au fil du 
temps, le code s'ameliore, la couverture de code s'elargit, et la confiance 
en celui-ci croit. Tout cela est rendu possible grace a cette approche 
pragmatique. L'etape suivante consiste done a ecrire des tests lors de 
l'implementation de nouvelles fonctionnalites. Ces derniers se montre- 
ront tres vite indispensables dans la suite du projet ! 

Le probleme avec la plupart des librairies de tests reste leur courbe 
d'apprentissage particulierement raide. C'est pourquoi Symfony fournit 
une librairie de tests tres simple, lime, afin de simplifier l'ecriture de tests. 

Si ce chapitre decrit en profondeur la librairie integree lime, rien 
n'empeche d'en utiliser une autre comme 1' excellent PHPUnit. 



Presentation du framework de test lime 

Initialisation d'un fichier de tests unitaires 

Tous les tests ecrits a partir du framework lime debutent avec le meme 
code : 

requi re_once di rname( FILE ) . '/■ ./bootstrap/unit . php' ; 

$t = new 1ime_test(l, new lime_output_co"lorO) ; 

Tout d'abord, le fichier d'initialisation unit. php est inclus afin de 
charger la configuration du projet et de la bibliotheque lime. Puis, un 
nouvel objet 1ime_test est cree, et le nombre de tests a executer est 
passe comme argument au constructeur de la classe. Le nombre de tests 
unitaires prevus permet a lime d'imprimer un message d'erreur en sortie 
au cas oil trop peu de tests seraient executes (par exemple, lorsqu'un test 
provoque une erreur fatale PHP). 

Decouverte des outils de tests de lime 

« Tester les fonctionnements d'une methode ou bien d'une fonction, 
c'est appeler cette derniere avec des points d'entree predefinis, puis com- 
parer la valeur quelle retourne avec la valeur de la sortie attendue ». 
Cette comparaison determine alors si un test passe ou bien s'il echoue. 



Pour faciliter cette comparaison, l'objet lime_test fournit plusieurs 
methodes : 



Tableau 8-1 Liste des methodes disponibles de l'objet lime_test 



Nom de la methode 


Description 


ok($test) 


Teste une condition et passe si elle est verifiee 


is($va"luel, $va"lue2) 


Compare deux valeurs et passe si elles sont egales (==) 


isnt($va"luel, $va"lue2) 


Compare deux valeurs et passent si elles sont differentes (!=) 


like($string, $regexp) 


Teste si la chaTne correspond a I'expression reguliere 


unli ke($stri ng , $regexp) 


Teste si la chaTne ne correspond pas a I'expression reguliere 


is_deeply($arrayl, $array2) 


Verifie que deux tableaux ont les memes valeurs 



Le fait que lime definisse autant de methodes de test peut paraitre etrange 
dans la mesure ou tous les tests peuvent etre ecrits a l'aide de la methode 
ok(). L'avantage de ces methodes alternatives reside dans les messages 
d'erreur beaucoup plus explicites qu' elles produisent lorsque le test echoue. 
De plus, elles permettent de faciliter la relecture des tests unitaires. Le 
tableau suivant liste quelques methodes utiles de l'objet 1 ime_test. 



Tableau 8-2 Liste des methodes de test de l'objet lime_test 



Nom de la methode 


Description 


failO 


Echoue toujours - pratique pour tester des exceptions 


passO 


Passe toujours - pratique pour tester des exceptions 


skip($msg, $nb_tests) 


Compte comme $nb_tests - pratique pour les tests conditionnels 


todoQ 


Compte comme un test - pratique pour les tests non encore ecrits 



Enfin, la methode comment ($msg) imprime un commentaire en sortie 
mais n'execute aucun test. 



Executer une suite de tests unitaires 

Tous les tests unitaires sont stockes dans le repertoire test/unit. Par 
convention, les tests sont nommes avec le nom de la classe (ou de la 
fonction) qu'ils testent, suffixes par Test. S'il est toujours possible 
d'organiser les fichiers du repertoire test/unit a sa guise, il est conseille 
de repliquer la structure du repertoire 1 i b/. 

Afin d'illustrer la mise en application des tests unitaires, la classe Jobeet 
sera testee via un nouveau fichier test/unit/JobeetTest.php qui con- 
tient le code suivant : 



Contenu du fichier test/unit/JobeetTest.php 

requi re_once di rname( FILE ) . 1 / ■ . /bootstrap/uni t . php ' ; 

$t = new lime_test(l, new lime_output_colorO) I 
$t->pass( 'This test always passes.'); 

II existe deux manieres de lancer les tests. La premiere consiste a exe- 
cuter directement le fichier PHP a l'aide du binaire php : 

| $ php test/unit/JobeetTest.php 

La seconde methode permet quant a elle d'executer la suite de tests uni- 
taires grace a la commande test: unit. 

j $ php symfony test: unit 



-Avork/jobeet $ php symfony test: unit Jobeet 
1..1 

ok 1 - Th is test always passes. 

Looks like everything went fine. 

-Avork/jobeet S | 



Figure 8-1 

Resultat d'execution d'une suite de tests unitaires 



Sous Windows, la ligne de commande ne permet malheureusement pas 
de mettre en evidence les resultats des tests en vert et rouge. 



Tester unitairement la methode slugifyO 

Afin d'illustrer plus concretement les principes de tests unitaires, c'est la 
methode Jobeet: : slugifyO qui sera testee dans un premier temps. II 
s'agit en effet de montrer les outils du framework lime ainsi que les 
bonnes pratiques a mettre en oeuvre lorsque Ton teste du code. 

Determiner les tests a ecrire 

La methode slugifyO a ete creee au cinquieme jour pour nettoyer une 
chaine afin que celle-ci soit utilisee en toute securite dans une URL. La 
modification de la chaine d'origine consiste en quelques transformations 
basiques comme la conversion des caracteres non ASCII par un tiret (-) 
ou le passage de la chaine en lettres minuscules. 



Tableau 8-3 Tableau de presentation du fonctionnement de la methode slugify 



Entree 


Sortie 


Sensio Labs 


sensio-labs 


Paris, France 


paris-france 
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Ecrire les premiers tests unitaires de la methode 



II est temps de controler que la methode slugifyO actuelle de la classe 
Jobeet realise correctement la transformation de la chaine de caracteres 
qui lui est passee en argument. Pour ce faire, le contenu du fichier de test 
doit etre remplace par celui-ci : 

Contenu du fichier test/unit/JobeetTest.php 

requi re_once di rname( FILE ) . '/■ ■ /bootstrap/unit. php' ; 

$t = new 1 ime_test(6 , new 1ime_output_color()) ; 

$t->is (Jobeet : :slugify('Sensio') , 'sensio') ; 
$t->is(Jobeet: :slugify('sensio labs'), 'sensio-labs') ; 
$t->is(Jobeet : : si ugifyC sensio labs'), 'sensio-labs'); 
$t->is (Jobeet : : si ugifyCparis, f ranee ' ) , ' paris-f ranee' ) ; 
$t->is(3obeet: :slugify(' sensio'), 'sensio'); 
$t->is(3obeet : : si ugifyC sensio '), 'sensio'); 

En pretant attention aux tests ecrits, il est important de constater que 
chaque ligne teste seulement un cas particulier. C'est un principe dont il 
faut toujours se souvenir lors de l'ecriture de tests unitaires. II est impor- 
tant de tester une seule chose a la fois ! 

II ne reste maintenant plus qua executer le fichier de tests. Si tous les tests 
passent comme prevu, la « barre verte » fera son apparition. Dans le cas con- 
traire, ce sera la « barre rouge » qui alertera que certains tests ont echoue. 



-/work/ jobeet $ php symfony test: unit Jobeet 
1..6 

ok 1 
ok 2 
ok 3 
ok 4 
ok 5 
ok 6 

Looks like everything went fine. 

~/work/jobeet S | 



Figure 8-2 

Resultat d'execution 
des tests unitaires de Jobeet::slugify() 



Si un test echoue, la sortie donnera quelques informations pour en connaitre 
les raisons. Cependant, si le fichier contient une centaine de tests, il sera 
probablement difficile d'identifier rapidement le comportement inhabituel. 



Commenter explicitement les tests unitaires 

Toutes les methodes de tests de lime prennent une chaine comme der- 
nier argument qui sert de description pour un test. C'est la un outil tres 
pratique dans la mesure ou cela oblige le developpeur a decrire lui-meme 
la portion de code testee. Cela peut egalement servir de documentation 
du comportement attendu d'une methode. Le code ci-dessous illustre un 



s 

c 

3 

exemple d'une serie de tests de la methode si ugi fy(), commentee par de -s 
courtes phrases : & 

require_once dirname( FILE ).'/■ ./bootstrap/unit. php' ; 00 

$t = new "lime_test(6, new lime_output_color()) ; 

$t->comment( ' : : si ugi fy() ' ) ; 

$t->is(Jobeet: :slugify('Sensio') , 'sensio', 1 ::slugify() 

converts all characters to lower case'); 

$t->is(Jobeet: :slugify('sensio labs'), 'sensio-labs ' , 

' : :s"lugify() replaces a white space by a -'); 

$t->is(Jobeet: :slugify('sensio labs'), 'sensio-labs' , 

' ::s1ugifyO replaces several white spaces by a single -'); 

$t->is(Jobeet: :slugify(' sensio'), 'sensio', '::s"lugify() 

removes - at the beginning of a string'); 

$t->is(Jobeet: :slugify('sensio '), 'sensio', ' ::s"lugify() 

removes - at the end of a string'); 

$t->i s(Jobeet : : si ugi fy( ' pari s , f ranee ' ) , 1 pari s-f ranee ' , 
' : :s"lugify() replaces non-ASCII characters by a -'); 



Figure 8-3 

Commentaires descriptifs des tests unitaires de Jobeet::slugify() 



-Avork/jobeet $ php symfony test: unit Jobeet 
1..6 

# ::slugifyO 

ok 1 - ::slugifyO converts all characters to lower case 
ok 2 - ::slugifyO replaces a white space by a - 
ok 3 - ::slugifyO replaces several white spaces by a single - 
ok 4 - ::slugifyO replaces non-ASCII characters by a - 
ok 5 - ::slugifyO removes - at the beginning of a string 
ok 6 - ::slugifyQ remove s - at the end of a strin g 
Looks like everything went fine. 
~/work/jobeet S | 



Remarque La couverture de code 

Lorsque Ton ecrit des tests, il arrive souvent d'en oublier pour certaines parties du code. 
Pour aider a verifier que tout le code est bien teste, Symfony fournit la tache 
test : coverage. En passant comme arguments de cette commande un fichier de test, ou 
un repertoire et un fichier, ou encore un repertoire de bibliotheque, cette derniere renverra en 
resultat le taux de couverture global du code. 
$ php symfony test:coverage test/unit/JobeetTest.php 

1 i b/]obeet . cl ass . php 
Si Ton souhaite savoir quelles lignes ne sont pas couvertes par les tests, il suffit de passer 
I'option — detai 1 ed. 

$ php symfony test:coverage --detailed test/unit/lobeetTest.php 

1 i b/lobeet . cl ass . php 
Toutefois, il est tres important de garder a I'esprit que lorsque la tache indique que le code est 
completement teste unitairement, cela signifie seulement que chaque ligne a ete executee 
mais pas que tous les cas possibles ont ete testes. 

Comme la tache test: cove rage depend de XDebug pour recolter ces informations, 
I'extension doit imperativement etre installee et activee en premier lieu. 



139 



La chaine de description du test est aussi un outil precieux lorsque Ton 
essaie de savoir ce qu'il faut tester. En effet, elle doit permettre d'expli- 
quer succinctement comment doit se comporter la fonction ou la 
methode testee. Ce bref resume du test suit un formalisme bien defini 
pour faciliter la lecture des resultats. Les tests de methodes statiques 
debutent tous par : : suivis du nom de la methode, tandis que les 
methodes classiques d'instance sont prefixees par ->. 

Implementer de nouveaux tests unitaires 
au fil du developpement 

Ajouter des tests pour les nouvelles fonctionnalites 

Le slug d'une chaine vide est une chaine vide. Un test unitaire peut le 
verifier. Or, une chaine vide dans une URL n'est pas conseillee. La 
methode slugifyO doit etre modifiee afin quelle retourne la chaine n-a 
en cas de chaine vide. 

La resolution de ce cas critique peut etre realisee en ecrivant le test avant 
l'implementation de la fonctionnalite ou bien apres. C'est simplement 
une question de gout. Neanmoins, ecrire le test avant permet d'avoir la 
certitude que le code implemente ce qui a ete prevu. 

$t->is(Jobeet: :slugify(' ') , 'n-a', '::s"lugify() converts the 
empty string to n-a'); 

A present, en executant la suite de tests unitaires, la barre rouge fait son 
apparition. Si ce n'est pas le cas, soit la fonctionnalite est deja imple- 
mentee, soit le test ne controle pas ce qu'il est suppose tester. Le code 
suivant corrige le slug resultant lorsqu'une chaine de caracteres vide est 
passee en argument. 

Debut de la methode slugifyO de la classe lib/Jobeet.class.php 

static public function si ugi fy($text) 
{ 

if (empty ($text)) 
{ 

return 'n-a'; 

} 



// 

} 



Le test doit maintenant passer comme prevu, et afficher la barre verte 
tant attendue, a condition d'avoir pense a mettre a jour le nombre de 
tests planifies dans le constructeur de l'objet "lime_test. Si ce n'est pas le 
cas, il y aura un message informant que 6 tests ont ete planifies mais que 
7 ont ete executes au total. Garder le compteur de tests planifies a jour 
est important car il permet de tenir le developpeur informe si le script de 
test « meurt » trop tot. 



Ajouter des tests suite a la decouverte d'un bug 

II est possible qu'un utilisateur du site rapporte un bug lors de sa naviga- 
tion sur le site : les liens presentant certaines offres d'emploi pointent 
vers une page d'erreur 404. Cette erreur provient du fait que des offres 
possedent un slug dont le nom de la societe, le poste ou la situation geo- 
graphique est vide. Apres verification, aucun champ de la base de don- 
nees n'a pourtant ete laisse vide. 

Ce bogue survient en fait a cause d'un probleme dans la methode sta- 
tique slugifyO. En effet, lorsque la chaine passee en parametre ne con- 
tient que des caracteres dits « non-ASCII », cette methode convertit la 
chaine en une chaine vide. Un refiexe bien naturel serait de corriger 
directement la methode slugifyO et ainsi de ne plus en entendre parler. 
Ce refiexe est a oublier dans un projet implementant un framework de 
tests unitaires. A defaut de corriger directement le bogue identifie, il va 
d'abord s'agir de creer un test, afin de s'assurer par la suite que ce pro- 
bleme ne se produise plus. 

$t->i sQobeet : : si ugi fy( ' - '), 'n-a', '::slugifyO converts a 
string that only contains non-ASCII characters to n-a'); 



Figure 8-4 

Resultats des tests unitaires de 
Jobeet::slugify() suite au bug decouvert 



-Avork/jobeet $ php symfony test: unit Jobeet 
1..8 

# :: slugifyO 

ok 1 - :: slugifyO converts all characters to lower case 

ok 2 - :: slugifyO replaces a white space by a - 

ok 3 - ::slugifyO replaces several white spaces by a single - 

ok 4 - :: slugifyO replaces non-ASCII characters by a - 

ok 5 - ::slugifyO renoves - at the beginning of a string 

ok 6 - ::slugifyO removes - at the end of a string 

ok 7 - : :slugifyQ replaces the empty string by n-a 

not ok 8 - ::slugifyO replaces a string that only contains non-ASCII c> 

# Failed test C/Users/fabien/work/symfony/dev/1.2yiib/vendor/lime/li 

# got: " 

# expected: 'n-a' 

Looks like you failed 1 tests of 8. 
~/work/jobeet $ | 



Ce n'est qu'apres avoir verifie que le test ne passe pas qu'il sera necessaire 
d'editer la classe Jobeet et de deplacer le controle de la chaine vide a la 
fin de la methode comme ci-dessous. 

' static public function si ugi fy($text) 
{ 

// ... 

if (empty ($text)) 
{ 

return 'n-a'; 

} 

return $text; 

} 

Desormais, le nouveau test ainsi que tous les autres passent correcte- 
ment. La methode si ugi fy() avait bel et bien un bogue malgre une cou- 
verture de code de 100 %. 

II est impossible de penser a tous les cas de bogues possibles lors de 
l'ecriture de tests. Neanmoins, lorsqu'un probleme est decouvert, un test 
pour celui-ci doit, dans l'ideal, etre ecrit avant de corriger le code. Cela 
signifie aussi que le code gagnera de plus en plus en qualite, ce qui est 
toujours une bonne chose. De plus, il ne faut pas oublier que le temps 
gagne sur le developpement de grosses applications est considerable. En 
n'ayant plus a tester ce genre de cas de figure a la main, le developpeur 
peut se concentrer davantage sur des portions de code plus critiques. 

Implementer une meilleure methode slugify 

II est important de rappeler que Symfony a ete cree par des Francais. De 
ce fait, les chaines contenant des caracteres accentues sont monnaie cou- 
rante et doivent done etre pris en charge par la methode si ugi fy () . Pour 
ce faire, la premiere etape consiste a ecrire un nouveau test unitaire avec 
une chaine contenant des caracteres accentues. 

$t->is(Jobeet: :slugify('Developpeur Web'), 'developpeur-web' , 
'::slugify() removes accents'); 

Bien evidemment, ce test doit echouer car les caracteres accentues sont 
automatiquement remplaces par des tirets et non par leur correspondant 
non accentue respectif. C'est un probleme recurent appele « translitera- 
tion ». Heureusement, si la librairie « i conv » est installee sur le serveur, 
elle realisera automatiquement le travail permettant d'eviter ce bogue. 



// code derive de http://php.vrana.cz/vytvoreni-pratelskeho- 
url . php 

static public function slugify($text) 
{ 

// replace non letter or digits by - 

Stext = preg_replace('~[A\\pL\d]+~u' , $text) ; 

// trim 

Stext = trim($text, '-'); 

// transliterate 

if (function exists('iconv')) 

{ 

$text = iconv('utf-8' , 'us-ascii//TRANSLIT' , $text) ; 

} 

// lowercase 

Stext = strtolower(Stext) ; 

// remove unwanted characters 

Stext = preg_replace('~[A-\w]+~' , ", Stext); 

if (empty (Stext)) 
{ 

return ' n-a' ; 

} 

return Stext; 

} 

Pour eviter ce genre de problemes, il est important de sauvegarder les 
fichiers PHP avec l'encodage UTF-8 dans la mesure ou c'est l'encodage 
par defaut de Symfony et qu'il est le seul utilise par « iconv » pour faire 
de la translitteration. 

Sachant que ce probleme se posera uniquement si la librairie iconv n'est 
pas disponible, le test ne sera execute qua cette condition. Aussi, le 
fichier de test doit etre modifie. 

if (function_exists(' iconv')) 
{ 

$t->is(Jobeet: :slugify('Developpeur Web'), 'developpeur-web' , 

'::slugify() removes accents'); 

} 

el se 
{ 

$t->skip(' : :slugify() removes accents - iconv not installed'); 

} 



Implementation des tests unitaires dans le 
framework ORM Doctrine 

Configuration de la base de donnees 



Tester unitairement un modele Doctrine est un peu plus complexe dans 
la mesure ou une connexion a la base de donnees est necessaire. 

Bien sur, il conviendrait d'utiliser la connexion a la base de donnees uti- 
lisee en environnement de developpement, mais c'est une bonne habi- 
tude a prendre que de creer une base de donnees dediee aux tests. De 
cette maniere, il est possible d'utiliser des donnees source de bogues dans 
les precedents developpements et ainsi de verifier la validite des tests. 

Au cours du premier chapitre, les environnements ont ete introduits 
comme un moyen de varier les parametres d'une application. Par defaut, 
tous les tests sont executes dans l'environnement de test ; une base de 
donnees doit done etre configuree pour ce dernier. 

$ php symfony configure: database --name=doctri ne 
--class=sfDoctrineDatabase --env=test 

"mysql : hostel ocal host; dbname=jobeet_test" root mYsEcret 



Le fichier de configuration config/ 
databases . yml est tres instructif. II permet de 
constater comment Symfony simplifie le changement 
de configuration en fonction d'un environnement. 



En COULISSE Organisation du fichier de 
configuration de Symfony 



L'option env indique a la tache que la configuration de la base de donnees 
est valable uniquement pour l'environnement de test. Lorsque cette com- 
mande a ete utilisee au chapitre 3, l'option env n'avait pas ete utilisee, c'est 
pourquoi la configuration a ete appliquee pour tous les environnements. 



Maintenant que la base de donnees a ete configuree, il est necessaire de 
l'initialiser en utilisant la commande doctrine :insert-sql. 



$ mysql admin -uroot -pmYsEcret create jobeet_test 
$ php symfony doctri ne : i nsert-sql --env=test 



Important Principes de configuration dans Symfony 

Le quatrieme chapitre montrait que des parametres provenant de fichiers 
de configuration pouvaient etre definis a plusieurs niveaux. 
Ces parametres de configuration peuvent egalement etre dependants 
d'un environnement. C'est vrai pour la plupart des fichiers de configura- 
tion utilises jusqu'a present: databases, yml, app.yml, 
view. yml et settings. yml. La cle principale presente dans ces 
fichiers correspond a l'environnement et indique que les parametres sont 
definis pour chaque environnement. 
# config/databases .yml 
dev: 



test: 
doctrine: 

class: sf Doctri neDatabase 
param: 

dsn: 'mysql :host=l ocal host ;dbname=jobeet_test' 



all : 



doctrine: 



class: sf Doctri neDatabase 



param: 

dsn: 'mysql :host=l ocal host ;dbname=jobeet' 
username: root 
password: null 



doctrine: 



class: sfDoctri neDatabase 
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Mise en place d'un jeu de donnees de test 

Maintenant que la base de donnees dediee aux tests a ete mise en place, 
il est temps de trouver une maniere pour y charger des informations de 
test. Lors du troisieme jour, la commande doctrine: data-load a ete 
abordee, mais pour les tests, les donnees devront etre rechargees a 
chaque execution afin de fixer la base de donnees dans un etat connu. 

La tache doctrine:data-load utilise interieurement la methode 
Doctri ne: : loadData pour charger les donnees. 

| Doctrine: :loadData(sfConfig: : get( ' sf_test_di r') . '/fixtures') ; 

La classe globale sfConfig peut etre utilisee pour obtenir le chemin 
complet vers un sous-repertoire du projet. Lutiliser permet notamment 
de pouvoir personnaliser la structure des dossiers par defaut. 

La methode loadData() prend un repertoire ou bien un nom de fichier 
comme premier argument. Elle peut aussi recevoir un tableau de dossiers 
et/ou de fichiers. 

Qyelques donnees initiales ont deja ete creees dans le repertoire data/ 
fixtures/. Pour les tests, les donnees utilisees seront deposees dans le 
repertoire test/fixtures/. Ces fichiers de donnees seront ensuite uti- 
lises par Doctrine pour les tests unitaires et fonctionnels. 

Pour l'instant, il suffit simplement de copier les fichiers du repertoire 
data/fixtures/ dans le repertoire test/fixtures. 

Verifier l'integrite du modele par des tests unitaires 
Initialiser les scripts de tests unitaires de modeles Doctrine 

Void quelques tests unitaires pour la classe de modele JobeetJob. Comme 
tous les tests unitaires Doctrine debuteront par le meme code, et pour res- 
pecter le principe DRY, un fichier Doctri ne . php dans le repertoire de test 
bootstrap/ doit etre cree. Ce dernier contient le code suivant : 

Contenu du fichier test/bootstrap/Doctrine.php 

incl ude(di rname( FILE ) . '/unit. php') ; 

Sconfiguration = ProjectConfiguration: :getApplicationConfiguration( 'frontend', 'test', true); 
new sfDatabaseManager(Sconfiguration) ; 

Doctrine: :loadData(sfConfig: : get( ' sf_test_di r') . '/fixtures') ; 
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En coulisse 

Connexion au serveur par Doctrine 

Doctrine se connecte a la base de donnees unique- 
ment s'il y a des requetes SQL a executer. 



METHODE Tenir a jour 
le compteur de tests planifies 

Chaque fois que des tests sont ajoutes, il ne faut 
pas oublier de mettre a jour le compteur de tests 
planifies dans le constructeur de la classe 
"lime_test. Pour Jobeet JobTest, il suffit 
de remplacer 1 par 3. 



Le script est suffisamment explicite de lui-meme : 

• comme pour les front controllers, un objet de configuration est initia- 
lise pour l'environnement de test : 

Sconfiguration = 

ProjectConfiguration: :getApp"licationConfiguration( 'frontend' , 
'test' , true) ; 

• puis un gestionnaire de base de donnees est cree. Ce dernier initialise 
la connexion Doctrine en chargeant le fichier de configuration 
databases . yml : 

| new sfDatabaseManager($configuration) ; 

• enfin, les donnees de tests sont chargees en base de donnees grace a 
Doctrine: :dataLoad() : 

j Doctrine: :1oadData(sfConfig: : get( ' sf_test_di r ' ) . '/fixtures') ; 

Tester la methode getCompanySlug() de I'objet JobeetJob 

Maintenant que tout est en place, les tests de la classe JobeetJob peuvent 
demarrer. Pour commencer, un fichier Jobeet JobTest. php doit etre cree 
dans le repertoire test/unit/model. 

Contenu du fichier test/unit/model/JobeetJobTest.php 

inc~lude(di rname( FILE ) . '/. ./■ ./bootstrap/Doctrine. php') ; 

$t = new lime_test(l, new "lime_output_co"lor()) ; 
$t->comment('->getCompanyS"lug() ') ; 

$job = Doctrine: :getTab1e(' JobeetJob')->createQuery()- 
>fetchOne() ; 

$t->is($job->getCompanySlug() , Jobeet: :slugify($job- 
>getCompany()) , ' ->getCompanyS"lug() return the slug for the 
company') ; 

Au passage, il est important de remarquer que le test porte seulement sur 
la methode getCompanySlug(), aucune verification n'etant effectuee pour 
savoir si le slug est correct ou non. En effet, c'est un test qui a deja ete 
effectue ailleurs. 

Tester la methode saveO de I'objet JobeetJob 

Ecrire des tests pour la methode saveO est legerement plus complexe. 
En effet, il s'agit ici de verifier que la creation de I'objet s'est bien pro- 
duite mais surtout que les donnees inserees dans la base de donnees sont 
bien celles auxquelles on s' attend. 
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$t->comment( ' ->save() ' ) ; 
$job = create_job(); 
$job->save() ; 

SexpiresAt = date('Y-m-d' , time() + 86400 * sfConfig: :get('app_active_days')) ; 
$t->is(date('Y-m-d' , strtotime($job->getExpiresAt())) , SexpiresAt, '->save() updates expires at 
if not set') ; 

$job = create_job(array('expi res_at' => '2008-08-08')); 
$job->save() ; 

$t->is(dateC'Y-m-d' , strtotime($job->getExpiresAt())) , '2008-08-08', '->save() does not update 
expires at if set'); 

function create job($defau"l ts = arrayO) 
{ 

static $category = null; 

if (is null ($category)) 
{ 

$category = Doctrine: :getTab1e(' JobeetCategory') 
->createQuery() 
->"limit(l) 
->fetchOne() ; 

} 

$job = new JobeetDobO; 

$job->f romAr ray (array merge (array ( 

'category id' => $category->getId() , 

'company' => 'Sensio Labs', 

'position' => 'Senior Tester ' , 

'location' => 'Paris, France', 

'description' => 'Testing is fun', 

'how to apply' => 'Send e-Mail ' , 

' emai "I ' => ' j ob@exampl e . com ' , 

'token' => rand(llll, 9999), 

'is activated' => true, 
), $defau"lts)) ; 

return $job; 

} 

Implementation des tests unitaires dans d'autres 
classes Doctrine 

II est des maintenant possible d'ajouter des tests unitaires pour chacune 
des classes Doctrine. Le processus d'ecriture de tests unitaires etant 
facile a assimiler, la tache devrait done etre tout aussi aisee. 



Lancer I'ensemble des tests unitaires du 
projet 

La tache test : uni t peut aussi servir a lancer tous les tests du projet : 
j $ php symfony test: unit 

Elle indique en sortie si chaque fichier de tests est passe ou bien a 
echoue. 



Figure 8-5 

Resultats d'execution 
de tous les tests unitaires du projet 



~/work/jobeet $ ./symfony test:unit 


ok 






All tests successful. 




Files.2. Tests-12 




-/work/jobeet S I 



Si la tache test: unit retourne le statut dubious pour un fichier de tests, 
cela indique que le script s'est interrompu avant la fin. Executer le fichier 
de tests seul donnera le message d'erreur exact. 



En resume... 



EN COULISSE 

9 000 tests unitaires pour Symfony 

Le framework Symfony lui-meme possede plus de 
9 000 tests unitaires a son actif pour en valider la 
fiabilite et la robustesse ! 



Tester une application est une chose necessaire ; et pourtant, certains 
lecteurs auront sans doute ete tentes de faire l'impasse sur ce chapitre... 
Nous sommes ravis de constater que ce n'est pas le cas ! 

Bien sur, seule une pratique intense de Symfony vous en revelera les 
fonctionnalites les plus interessantes, ainsi que la philosophie de deve- 
loppement et les bonnes pratiques qu'il induit. Tester fait justement 
partie de ces pratiques vertueuses et un jour ou l'autre, les tests unitaires 
sauveront vos applications du desastre. 

Les tests, en effet, garantissent la solidite du code et offrent la liberte de 
le remanier sans risque de tout casser. lis sont de veritables garde-fous 
car ils vous alertent en cas de modification intempestive cassant le fonc- 
tionnement de I'ensemble ou induisant une regression ailleurs. 

Le chapitre suivant sera consacre aux tests fonctionnels. Ils seront 
d'ailleurs abordes et implemented dans les modules job et category. 
Prenez un peu de temps d'abord pour ecrire quelques tests unitaires pour 
les classes de modele de Jobeet ; cet exercice sera excellent pour vous 
preparer au chapitre suivant. . . 
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symfony 



~/work/jobeet $ ./synfony test: functional frontend categoryActions 

# get /category/index 

ok 1 - request parameter module is category 
not ok 2 - request parameter action is index 

tf Failed test CAJsers/fabien/twrk/symfony/dev/l.2/lib/test/sfTesterRequest. class. php at line 48) 

# got: 'show' 
# expected: 'index' 

not ok 3 - status code is 200 

# Failed test C/Users/fabien/»»ork/symfony/dev/1.2/lib/test/sfTesterResponse. class. php at line 257) 
n got: 404 

ft expected: 200 

ok 4 - response selector body does not match regex /This is a temporary page/ 
1..4 

Looks like you failed 2 tests of 4. 

~/work/jobeet $ | 




Les tests fonctionnels 



MOTS-CLES 



Parmi les autres types de tests automatises figurent 

les tests fonctionnels. Ces derniers permettent de valider 

le comportement general des fonctionnalites d'une application 

en simulant la navigation d'un utilisateur dans son navigateur 

Internet. Symfony integre par defaut un sous-framework 

de tests fonctionnels puissant qui simplifie l'ecriture de 

scenarios de tests fonctionnels grace a une interface fluide. 



► Tests fonctionnels 

► Objets sfBrowser 
et sfTestFunctional 

► Testeurs Request et Response 



Le chapitre precedent visait a expliquer comment tester unitairement les 
classes de Jobeet a partir de la librairie lime embarquee dans Symfony. 
Dans cette neuvieme partie, ce sera l'occasion de decouvrir et d'ecrire des 
tests pour les fonctionnalites deja implementees dans les modules job et 
category. 

Decouvrir ('implementation des tests 
fonctionnels 

Les tests fonctionnels constituent un outil efficace pour tester une appli- 
cation du debut a la fin, c'est-a-dire de la requete construite par le navi- 
gateur jusqu'a la reponse envoyee par le serveur. Leur champ d'action 
s'etend a toutes les couches de 1' application comme le routage, le 
modele, les actions et les templates. Cette section definit dans un pre- 
mier temps la notion de tests fonctionnels puis explique comment ils 
sont integres au sein du framework Symfony. 

En quoi consistent les tests fonctionnels ? 

Concretement, les tests fonctionnels ressemblent de tres pres aux tests 
manuels qu'un developpeur realise dans son navigateur. L'approche 
manuelle reste encore le schema le plus couramment employe pour tester 
une application. Des lors qu'une fonctionnalite est ajoutee ou modifiee, il 
est coutume d'ouvrir le navigateur pour verifier que celle-ci se comporte 
correctement en controlant les differents objets qui composent la page de 
rendu final. Les liens, les images, les tableaux, les messages d'informa- 
tions, etc., figurent parmi ces elements qui servent de points de controle. 

Toutefois, les tests manuels posent quelques problemes car ils sont avant 
tout penibles et fastidieux a realiser. II en resulte alors tout naturellement 
de multiples consequences sur leur efficacite et leur viabilite. Au bout d'un 
certain temps passe a developper une application, le developpeur aura ten- 
dance a se lasser et a survoler certaines fonctionnalites de l'application, 
d'ou la necessite d'automatiser la procedure de test. La question qui se 
pose alors est la suivante : « qu'est-ce qu'un test efficace et viable ? » 

Un test viable, c'est avant tout un plan d'action que Ton doit etre capable 
de repeter a l'identique et a l'infini. C'est done la tout l'interet de faire 
appel aux services de la machine plutot qu'aux competences de l'etre 
humain. En effet, ce dernier ne sera jamais en mesure de reproduire a 
l'identique et sur une periode infinie le meme test. Les tests fonctionnels 
sont done apparus pour repondre a cette problematique, et c'est pour cette 
raison qu'ils s'integrent parfaitement dans l'environnement de Symfony. 



Implementation des tests fonctionnels 

Dans Symfony, les tests fonctionnels offrent une maniere simple de 
decrire les scenarios de test. Chaque scenario peut etre joue automati- 
quement a volonte en simulant 1' experience que possede un utilisateur 
dans son navigateur. Au meme titre que les tests unitaires, ils apportent 
l'assurance que le code est fonctionnel et sans dysfonctionnements. 

II faut tout de meme garder a l'esprit que le framework de tests fonction- 
nels ne remplace en aucun cas des outils tels que Selenium. Selenium 
s'execute directement dans le navigateur afin d'automatiser les tests sur 
plusieurs plateformes, navigateurs et autres. Cet outil est egalement connu 
pour sa capacite a pouvoir tester le code Javascript d'une application. 

Manipuler les composants de tests 
fonctionnels 

Le framework interne de tests fonctionnels de Symfony fournit de nom- 
breux composants pour faciliter l'ecriture de tests de differentes natures. 
Le premier mis a 1' etude dans ces prochaines lignes permet de simuler le 
comportement d'un navigateur web. 

Simuler le navigateur grace a l'objet sfBrowser 

Les tests fonctionnels de Symfony s'executent a travers un navigateur un 
peu special implemente par la classe sfBrowser. Celui-ci agit comme un 
navigateur taille sur mesure pour l'application et directement connecte a 
celle-ci, sans necessiter de serveur web. 

Ce pseudo navigateur donne par exemple acces a tous les objets internes 
de Symfony avant et apres chaque requete, ce qui offre l'opportunite de 
les introspecter et d'effectuer les verifications souhaitees en cours d'exe- 
cution du programme. 

Tester la navigation en simulant le comportement d'un veritable 
navigateur 

La classe sfBrowser dispose d'un certain nombre de methodes qui simu- 
lent la navigation comme le permet un navigateur web classique. Le 
tableau ci-dessous decrit celles qui sont principalement utilisees dans 
l'ecriture de scenarios de tests. 



Tableau 9-1 Liste des methodes de I'objet sfBrowser 



Nom de la methode 


Description 


get() 


Recupere une URL 


post() 


Poste des donnees vers une URL 


ca11() 


Appelle une URL (utilise pour les methodes PUT et DELETE) 


back() 


n ■ 1 ' ' 1 ■ 1 1/1 ■ ■ 

Retourne vers la page precedente de 1 historique 


forwardO 


Dirige vers la page suivante de I'historique 


reload () 


Recharge la page courante 


click() 


Clique sur un bouton ou un lien 


selectO 


Selectionne un bouton radio ou une case a cocher 


deselectO 


Deselectionne un bouton radio ou une case a cocher 


restart() 


Reinitialise le navigateur 



Le code suivant illustre quelques exemples d'utilisation des methodes de 
la classe sfBrowser. 



$browser = new sfBrowser(); 

$browser-> 
get(7')-> 
click('Design')-> 

get('/category/programmi ng?page=2 ')-> 

get ('/category/prog ramming' , arrayCpage' => 2))-> 

post( ' search ' , array( ' keywords ' => 'php')); 

Modifier le comportement du simulateur de navigateur 

La classe sfBrowser contient aussi quelques methodes complementaires 
qui offrent la possibilite de configurer le comportement du navigateur, 
comme le montre le tableau suivant. 



Tableau 9-2 Liste des methodes de I'objet sfBrowser qui permettent 
de configurer le comportement du navigateur 







setHttpHeaderO 


Definit un en-tete HTTP 


setAuthO 


Definit les droits d'authentification de base 


setCookieO 


Fixe un cookie 


removeCooki e() 


Retire un cookie 


clearCookiesO 


Nettoie tous les cookies en cours 


followRedi rect() 


Suit la redirection declenchee 



Pour fonctionner, les tests fonctionnels necessitent l'utilisation d'un 
autre objet : l'objet sfTestFunctional. Cet dernier contient un ensemble 
de testeurs capables d'analyser les differents objets internes du fra- 
mework comme la requete, la reponse, le routage, les formulaires et bien 
d'autres encore. 

Preparer et executer des tests fonctionnels 

La plupart des tests fonctionnels peuvent etre realises a l'aide des objets 
sfBrowser et lime, et leurs methodes respectives telles que getRequestO 
ou getResponseO. Neanmoins, l'ideal est de posseder un moyen d'ins- 
trospecter les objets internes de Symfony pour le scenario en cours. 
Heureusement, le framework fournit son lot de methodes de test a l'aide 
de la classe sfTestFunctional. Le constructeur de cette derniere accepte 
une instance de la classe sfBrowser comme argument. 

Comprendre la structure des fichiers de tests 

L'objet sfTestFunctional delegue tous les tests a des objets « testeurs », 
dont la plupart sont embarques par defaut dans Symfony. Chaque tes- 
teur est en realite un objet qui etend la classe sfTester, ce qui permet par 
exemple de creer ses propres testeurs ou bien d'enrichir les existants en 
profitant de l'heritage de classes. 

Dans un projet Symfony, tous les fichiers de tests fonctionnels se trou- 
vent dans le repertoire test/functional/. Dans le cas present de l'appli- 
cation developpee, tous sont situes dans le sous-dossier test/ 
functional /f rontend puisque chaque application dispose de son propre 
repertoire. Celui-ci contient deja deux fichiers qui ont ete automatique- 
ment generes lorsque les deux modules job et category ont ete crees. Les 
fichiers categoryActionsTest.php et jobActionsTest.php renferment 
chacun quelques exemples de tests fonctionnels tres basiques comme le 
presente le listing de code ci-apres. 

Mettre en place un jeu de tests fonctionnels en utilisant le chaTnage 
de methodes 

Tests fonctionnels autogeneres pour le module category dans le fichier test/ 
functional/frontend/categoryActionsTestphp 

incl ude(di rname( FILE ) .'/■■/■ ./bootstrap/functional . php') ; 

Sbrowser = new sfTestFunctional (new sf BrowserO) ; 

$browser-> 

get ( ' /category/i ndex ' ) -> 



with(' request ')->beginO-> 

i sParameter( ' modul e ' , 'category')-> 

i sParameter( ' action ' , 'index')-> 
end()-> 

with(' response')->begin()-> 
isStatusCode(200)-> 

checkE1ement('body' , '!/This is a temporary page/')-> 
endO 

A premiere vue, ce script peut paraitre etrange et peu commode pour la 
plupart des developpeurs car sa syntaxe est peu singuliere. Toutes les 
methodes appelees sur l'objet sfTestFunctional (Sbrowser) sont en effet 
chainees afin d'assurer une interface fluide d'ecriture de scenarios mais 
aussi une meilleure lisibilite du code. 

Comment cette syntaxe est-elle rendue possible ? C'est techniquement 
enfantin puisque toutes les methodes implementees dans les classes 
sfBrowser et sfTestFunctional retournent toujours la reference a l'objet 
lui-meme, conservee dans la variable $thi s. 

Mettre en place un jeu de tests fonctionnels sans drainage de methodes 

Le code ci-dessous est strictement identique au dernier avec le chainage 
des methodes en moins. Le resultat de la comparaison des deux syntaxes 
est clair : la premiere facilite grandement la lisibilite du code tandis que 
la seconde la reduit en raison de l'importance de bruit genere par la repe- 
tition de la variable $browser. 

include(di rname( FILE ) . '/■ ■/■ ./bootstrap/functional .php') ; 

Sbrowser = new sfTestFunctional (new sf BrowserO) ; 

$browser->get(' /category/index' ) ; 
$browser->with(' request')->begin() ; 
$browser->isParameter('module' , 'category') ; 
$browser->isParameter('action' , 'index') ; 
$browser->end() ; 

$browser->with(' response ') ->begi n() ; 
; $browser->isStatusCode(200) ; 
$browser->checkElement('body' , '!/This is a temporary page/'); 
$browser->end() ; 

Effectuer des tests dans le contexte d'un bloc testeur 

Tous les tests sont executes dans le contexte d'un bloc testeur. 

Le bloc d'un testeur commence par with ('TESTER NAME')->begin() et 
s'acheve par end() comme le montre l'exemple de code suivant. 



$browser-> 

wi th ( ' request ' ) ->begi n () -> 

isParameter('module' , ' category ' )-> 

isParameterC action' , 'index')-> 
endO; 

Ce code verifie si le parametre module de la requete (testeur request) 
equivaut bien a la valeur category, et que le parametre action contient 
lui aussi la valeur index. Lorsque Ton souhaite appeler seulement une 
methode sur un testeur, il n'est pas necessaire de creer un bloc de tests : 
with(' request')->isParameter('module' , 'category'). 

Decouvrir le testeur sfTesterRequest 

Le testeur sfTesterRequest fournit des methodes qui permettent 
d'introspecter et de tester les valeurs des proprietes de l'objet 
sfWebRequest. Le tableau ci-dessous presente quelques-unes d'entre elles. 



Tableau 9-3 Liste des methodes de l'objet sfTesterRequest 







i sParameterO 


Controle la valeur d'un parametre de la requete 


isFormatO 


Verifie le format d'une requete 


isMethodO 


Verifie la methode (GET, POST, PUT, DELETE...) 


hasCooki e() 


Indique si la requete a un cookie correspondant au nom donne en parametre 


isCookie() 


Teste la valeur d'un cookie 



Un testeur sfTesterResponse existe aussi afin de pouvoir controler les 
differents parametres que le serveur envoie au client en guise de reponse 
a une requete HTTP. 



Decouvrir le testeur sfTesterResponse 

Le testeur sfTesterResponse fournit quant a lui des methodes qui per- 
mettent d'introspecter et de tester les valeurs des proprietes de l'objet 
sfWebResponse. Le tableau ci-dessous en presente quelques unes. 



Tableau 9-4 Liste des methodes de l'objet sfTesterResponse 



Nom de la methode 


Description 


checkEl ement() 


Verifie si un selecteur CSS de la reponse correspond a un critere 


i sHeaderO 


Controle la valeur d'un en-tete 


isStatusCodeO 


Controle le code de statut de la reponse (200, 301, 404, 500...) 


i sRedi rectedQ 


Verifie si la reponse courante est redirigee 



Executer les scenarios de tests fonctionnels 

Les tests fonctionnels s'executent de la meme maniere que les tests uni- 
taires vus au chapitre precedent. II existe trois manieres de lancer des 
tests fonctionnels : 

• la premiere consiste a appeler directement le fichier PHP et de l'exe- 
cuter a l'aide du binaire PHP comme le presente le code suivant : 

| $ php test/functional /f rontend/categoryActionsTest.php 

• une commande Symfony permet de realiser exactement la meme 
chose en simplifiant la syntaxe : 

$ php symfony test: functional frontend categoryActions 



Figure 9-1 

Resultat d'execution 
des tests fonctionnels 
du module « category » 



J ./symfony test : functional frontend categoryActions 

# get /category/index 

ok 1 - request parameter module is category 
not ok Z - request parameter action is index 

# Failed test C/Users/fabien/worl</syimfony/dev/1.2/lib/test/sfTesterRequest. class. php at line 48) 

# got: 'show' 

# expected: 'index' 

not ok 3 - status code is 200 

# Failed test C/Users/fabien/work/syiiifony/dev/1.2/ltb/test/sfTesterResponse. class. php at line 257) 

# got: 404 

# expected: 200 

ok 4 - response selector body does not match regex /This is a temporary page/ 
1..4 



-Avork/jobeet S 



• enfin, comme pour les tests unitaires, la commande test: functional 
sert a lancer tous les tests fonctionnels d'une meme application en 
omettant simplement le second argument : 

$ php symfony test:functiona1 frontend 



Charger des jeux de donnees de tests 

Au meme titre que les tests unitaires pour le modele de donnees Doc- 
trine, des jeux de donnees de tests doivent etre charges en base de don- 
nees chaque fois qu'un fichier de tests fonctionnels est execute. Le code 
ecrit au chapitre precedent qui remplit cette tache est reutilisable ici de la 
meme maniere. 

include(di rname( FILE ) . '/■ ■/■ ./bootstrap/functional .php') ; 

Sbrowser = new JobeetTestFunctional (new sfBrowserO) ; 

Doctri ne : : 1oadData(sfConf i g : : get( ' sf_test_di r ' ) . 1 /fi xtures 1 ) ; 
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Charger des donnees dans un fichier de tests fonctionnels est un peu J 
plus simple qu'avec les tests unitaires puisque la base de donnees est deja % 
initialisee par le script d'amorcage. Comme pour les tests unitaires, il est J 
bien evidemment inutile de copier et coller ce bout de code dans chaque ^ 
fichier de test. La meilleure maniere de proceder est de mutualiser ce 
code dans une classe de tests fonctionnels dediee qui herite de 
sfTestFunctional. 

Contenu du fichier lib/test/JobeetTestFunctional.class.php 

class JobeetTestFunctional extends sfTestFunctional 
{ 

public function loadDataO 
{ 

Doctrine: : loadData(sfConfig: :get( ' sf_test_di r ' ) . '/fixtures ' ) ; 
return $this; 

} 

} 



Ecrire des tests fonctionnels pour le 
module d'offres 

Ecrire des tests fonctionnels revient exactement a jouer un scenario dans un 
navigateur web. II s'agit en effet de tester que chaque fonctionnalite testee 
reagit comme le definit son cahier des charges. De plus, les tests fonction- 
nels ont pour objectifs de verifier que le rendu final de chaque page corres- 
pond exactement a ce que le developpeur a prevu dans son code. 

Le second chapitre de cet ouvrage decrit de maniere non exhaustive tous 
les besoins fonctionnels de i'application. En y reflechissant bien, ces cas 
d'utilisation sont exactement la description litterale des scenarios de tests 
fonctionnels a ecrire. Pour la page d'accueil du module d'offres d'emploi, 
on ne compte pas moins de cinq tests obligatoires qui seront developpes 
juste apres : 

• les offres d'emploi expirees ne sont plus affichees ; 

• seulement N offres d'emploi actives sont listees par categorie ; 

• une categorie possede un lien vers sa page dediee s'il y a trop d'offres 
d'emploi ; 

• les offres d'emploi sont listees par date ; 

• chaque offre d'emploi de la page d'accueil est cliquable. 

II est temps de demarrer avec le premier scenario de cette liste. 
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Les offres d'emploi expirees ne sont pas affichees 

Ce test fonctionnel tient en quelques lignes de code PHP puisqu'il s'agit 
tout simplement de verifier que la page d'accueil ne contient aucune 
occurrence du selecteur CSS 3 passe en parametre de la methode 
checkElementO du testeur response. 

Contenu du fichier test/functional/frontend/jobActionsTest.php 

include(di rname( FILE ) . '/■ ■/■ ./bootstrap/functional .php') ; 

$browser = new JobeetTestFunctional (new sfBrowserO) ; 
$browser->loadData() ; 

$browser->info('l - The homepage')-> 

get('/')-> 

with(' request')->begin()-> 

i sParameter( ' modul e ' , 'job')-> 

i sParameter( ' action ' , 'index')-> 
end()-> 

wi th(' response' )->begin()-> 

info(' 1.1 - Expired jobs are not listed')-> 
checkElement(' .jobs td.position:contains("expired") ' , 
I false) -> 

end() 

» 

Comme avec lime, un message d'information peut etre insere en appe- 
lant la methode i nfo() dans le but de rendre la sortie plus lisible et com- 
prehensible. Le controle de l'exclusion des offres d'emploi de la page 
d'accueil se traduit par le fait que le selecteur CSS 3 .jobs 
td. position: contains ("expired") ne doit en aucun cas etre present 
dans le contenu HTML de la reponse. 

Si Ton se souvient des fichiers de donnees de tests, la seule offre d'emploi 
expiree contient la chaine « expired » en guise de poste. Lorsque le 
second argument de la methode checkElementO est un booleen, la 
methode teste l'existence des nceuds qui correspondent au selecteur 
CSS 3. La methode checkElementO supporte d'ailleurs la plupart des 
selecteurs CSS 3 existants. 

Seulement N offres sont listees par categorie 

Tester qu'une categorie presente bien un certain nombre fini d'offres est 
relativement simple avec les selecteurs CSS et la methode 
checkElementO. En effet, il s'agit ici de compter le nombre de lignes du 
tableau HTML pour une meme categorie. Pour faciliter davantage le 
test, il suffit de s'appuyer sur le nom de la categorie qui est genere dans le 
code HTML sous forme d'une classe CSS. 



Suite du contenu du fichier test/functional/frontend/jobActionsTestphp 



$max = sfConfig: :get('app max jobs on homepage') ; 

$browser->i nfo( ' 1 - The homepage ') -> 
get('/')-> 

info(sprintf (' 1.2 - Only %s jobs are listed for a category', 
$max))-> 

withC response')-> 

checkElementC -category programming tr', $max) 

La methode checkElementC) est egalement capable de verifier qu'un 
selecteur CSS correspond a un nombre fini de noeuds dans le document, 
en passant un entier comme second argument. 

Un lien vers la page d'une categorie est present 
lorsqu'il y a trop d'offres 

Dans Jobeet, lorsqu'une categorie regroupe sur la page d'accueil plus 
d'offres d'emploi que le nombre maximum d'offres autorise pour cette der- 
niere, un lien « more jobs » est affiche. L'objectif de ce test fonctionnel con- 
siste a verifier la presence ou l'absence du lien en fonction du nombre 
d'offres d'emploi dans chaque categorie. D'apres les fichiers de donnees de 
tests, seule la categorie « Programming » est censee accueillir ledit lien. 

Suite du fichier test/functional/frontend/jobActionsTest.php 

$browser->i nfo( ' 1 - The homepage ')-> 
get('/')-> 

info(' 1.3 - A category has a link to the category page only 
if too many jobs')-> 

with(' response ')->begin()-> 

checkElementC .category design .more jobs', false)-> 
checkElementC .category programming .more jobs' )-> 

end() 

> 

Ces tests verifient qu'il n'y a pas de lien « more jobs » pour la categorie 
« design », c'est-a-dire que le selecteur CSS . category_design 
. more_jobs existe nulle part dans le document. lis testent en revanche 
que le lien « more jobs » est bien present pour la categorie 
« programming », done que le selecteur CSS . category_programming 
.more_jobs existe. 



Les offres d'emploi sont trices par date 

Ce test est un peu plus complexe a mettre en oeuvre que les precedents. . . 
En effet, pour tester si les offres d'emploi sont effectivement ordonnees 
par date, il faut verifier que la premiere offre d'emploi qui apparait dans 
la page d'accueil correspond bien a celle que Ton attend. Ce resultat peut 
etre obtenu en controlant que l'URL contient la cle primaire attendue. 
Or, les cles primaires ne sont pas fixes et peuvent done varier entre deux 
executions d'un meme fichier de tests fonctionnels. Cela est du au fait 
que Doctrine recharge les donnees de test dans la base de donnees a 
chaque nouvelle execution du script. L'astuce pour y parvenir est en fait 
triviale puisqu'il s'agit de recuperer l'objet Doctrine de la base de don- 
nees comme le montre le code suivant. 

$q = Doctrine Query: :create() 
->select('j.*') 
->from(' JobeetJob j') 
->leftJoin(' j . JobeetCategory c') 
->where('c.s"lug = ?' , 'programming') 
->andWhere( ' j .expires at > ?', date('Y-m-d" , time())) 
->orderBy('j .created at DESC); 

$job = $q->fetchOne() ; 

$browser->i nfo( ' 1 - The homepage')-> 
get(V)-> 

info(' 1.4 - Jobs are sorted by date')-> 
wi th ( ' response ' ) ->begi n () -> 

checkE1ement(sprintf (' .category programming tr: first 
a[href*="/%d/"] ' , $job->getId()))-> 

endO 

Quelques explications s'imposent malgre tout dans la mesure oil le code 
presente se revele un peu complexe. Tout d'abord, la requete Doctrine 
recupere l'offre d'emploi la plus recente pour la categorie dont le slug a 
pour valeur « programming ». 

Puis, la methode checkEl ement() teste la presence du selecteur CSS 3 passe 
en parametre. Ce dernier est formate par la fonction spri ntf () de maniere a 
signifier que la premiere offre d'emploi (tr:first) de la categorie 
« programming » (. category_prog ramming) possede un lien dont l'attribut 
href contienne la cle primaire de l'objet attendu (a[href*="/%d/"]). 

Bien que ce test fonctionne parfaitement, un besoin de remaniement se 
fait ressentir. En effet, la recuperation de la premiere offre d'emploi de la 
categorie « programming » est potentiellement reutilisable ailleurs dans 
les tests. Le code ne peut en revanche etre deplace vers la couche du 
modele dans la mesure ou il est purement specifique aux tests. De ce 



postulat, on en deduit clairement que la meilleure place a lui consacrer 
est la classe JobeetTestFunctional creee plus tot dans ce chapitre. Celle- 
ci se comporte comme une classe de tests fonctionnels propre a l'envi- 
ronnement de test. 

Methode a ajouter au fichier lib/test/JobeetTestFunctional.class.php 

class JobeetTestFunctional extends sfTestFunctional 
{ 

public function getMostRecentProgrammingJob() 
{ 

$q = Doctrine Query : :create() 

->select('j.*') 

->from(' JobeetJob j') 

->1eftDoin(' j . JobeetCategory c') 

->where('c.s"lug = ?', 'programming'); 
$q = Doctrine: :getTable(' JobeetJob')- 
>addActive3obsQuery($q) ; 

return $q->fetchOne() ; 

} 

// ... 

} 

Le code des tests fonctionnels precedent peut alors etre reduit a celui qui 
suit. 

Suite du fichier test/functional/frontend/jobActionsTest.php 

$browser->i nfo( ' 1 - The homepage ')-> 
get(7')-> 

info(' 1.4 - Dobs are sorted by date')-> 
with(' response ')->begin()-> 

checkEl ement(spri ntf ( ' . category_programmi ng tr : fi rst 
a[href*="/%d/"] ' , 

$browser->getMostRecentProgrammi ngJobO ->getld() ) ) -> 
endQ 



Chacune des offres de la page d'accueil est cliquable 

Pour tester le lien d'une offre de la page d'accueil, il suffit de simuler un 
clic sur le texte « Web Developper ». Comme il y en a plusieurs possibles 
sur cette page, le test force explicitement le navigateur a cliquer sur le 
premier qu'il trouve (arrayC position ' => 1)). 



Chaque parametre de la requete est ensuite teste pour s' assurer que le 
routage a correctement fait son travail. 

$browser->info('2 - The job page')-> 
get(7')-> 

info(' 2.1 - Each job on the homepage is clickable and give 
detailed information')-> 

click('Web Developer', arrayO, arrayCposition' => l))-> 

with(' request ')->beginO-> 

isParameterC module' , 'job')-> 
isParameterC'action' , 'show')-> 
isParameterC 'company slug' , 'sensio-labs')-> 
isParameterC'location slug' , ' pari s-f ranee ')-> 
isParameterC'position slug' , 'web-developer ')-> 
isParameterC id' . $browser->getMostRecentProgrammingDob()- 
>getId())-> 

endQ 



Autres exemples de scenarios de tests pour 
les pages des modules job et category 

Cette section fournit tout le code necessaire pour tester les pages des 
modules job et category. En lisant le code avec attention, on apprend 
quelques nouvelles astuces pratiques. 

Contenu du fichier lib/test/JobeetTestFunctional.class.php 

class JobeetTestFunctional extends sfTestFunctional 
{ 

public function loadDataO 
{ 

Doctrine: :loadData(sfConfig: :get( ' sf_test_di r ') . '/fixtures ') ; 
return Sthis; 

} 

public function getMostRecentProgrammi ng]ob() 
{ 

$q = Doctri ne_Query : : createO 

->select(' j . *') 

->f rom(' Jobeetlob j') 

->leftJoin(' j . JobeetCategory c') 

->where('c.slug = ?', 'programming'); 
$q = Doctrine: :getTable(' JobeetJob')->addActive]obsQuery($q) ; 

return $q->fetchOne() ; 

} 



— 



// Recuperation d'une off re expiree 
public function getExpiredJobO 
{ 

$q = Doctrine Query : :create() 
->from(' JobeetJob j') 

->where('j .expires at < ?', date('Y-m-d' , time())); 
return $q->fetchOne() ; 

} 

} 



Contenu du fichier test/functional/frontend/jobActionsTest.php 

include(di rname( FILE ) .'/■■/■ ./bootstrap/functional . php' ) ; 

$browser = new JobeetTestFunctional (new sfBrowserO); 
$browser->loadData() ; 

$browser->i nfo( ' 1 - The homepage ')-> 

get('/')-> 

with(' request ')->begin()-> 

isParameter('module' , 'job')-> 

isParameter('action' , 'index')-> 
end()-> 

with(' response ')->begin() -> 

info(' 1.1 - Expired jobs are not listed')-> 

checkElement(' .jobs td. position : contai ns("expi red") ' , false)-> 
end() 



$max = sfConfig: :get('app_max_jobs_on_homepage') ; 

$browser->info('l - The homepage ')-> 

info(sprintf (' 1.2 - Only %s jobs are listed for a category', 

$max))-> 
with(' response')-> 

checkElement(' . category_programmi ng tr', $max) 



$browser->info('l - The homepage')-> 

get('/')-> 

info(' 1.3 - A category has a link to the category page only if 
too many jobs')-> 

with(' response ')->begin()-> 

checkElement(' .category_design .more_jobs', false)-> 
checkElement(' . category_programmi ng .more_jobs')-> 

endQ 



$browser->i nfo( ' 1 - The homepage ')-> 
info(' 1.4 - Jobs are sorted by date')-> 
with(' response ')->begin() -> 
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checkElement(sprintf (' . category_programmi ng tr:first a[href*= 
"/%d/"] ' , $browser->getMostRecentProgramming]ob()->getId()))-> 
endQ 



$browser->info('2 - The job page')-> 

info(' 2.1 - Each job on the homepage is clickable and give 
detailed information')-> 

click('Web Developer', arrayO, array( ' position ' => l))-> 
with(' request')->begin()-> 

isParameter(' module' , 'job')-> 
isParameter('action' , 'show')-> 
isParameter('company_slug' , 'sensio-labs')-> 
isParameter('location_slug' , ' pari s-f ranee ' )-> 
isParameter('position_slug' , 'web-developer')-> 
isParameter('id' , $browser->getMostRecentProgrammingJob()-> 
getId())-> 

end()-> 

info(' 2.2 - A non-existent job forwards the user to a 404')-> 
get ( ' /job/ f oo-i nc/mi 1 ano-i tal y/O/pai nter ' ) -> 
wi th ( ' response ' ) ->i sStatusCode (404) -> 

info(' 2.3 - An expired job page forwards the user to a 404')-> 
get(spri ntf ( '/job/sensio-1 abs/pari s-f rance/%d/web-developer ' , 

$browser->getExpi red] ob()->getId ()))-> 
wi th ( ' response ' ) ->i sStatusCode (404) 



Contenu du fichier test/functional/frontend/categoryActionsTest.php 

include(di rname( FILE ) .'/../. ./bootstrap/functional .php') ; 

; Sbrowser = new JobeetTestFunctional (new sf BrowserO) ; 
' $browser->loadData() ; 

$browser->i nfo( ' 1 - The category page')-> 

info(' 1.1 - Categories on homepage are clickable')-> 
get('/')-> 

cl i ck( ' Prog rammi ng ' ) -> 
with(' request ')->begin() -> 

isParameter('module' , 'category')-> 

isParameter('action' , 'show')-> 

isParameter('slug' , 'programming')-> 
end()-> 

i nfo(spri ntf ( ' 1.2 - Categories with more than %s jobs also have 
a "more" link', sfConfig: :get('app_max_jobs_on_homepage')))-> 
get('/')-> 
click('22')-> 

with(' request')->begin()-> 

isParameter('module' , 'category')-> 
isParameter('action' , 'show')-> 



isParameter('slug' , 'programming')-> 
end()-> 

i nfo(spri ntf ( ' 1.3 - Only %s jobs are listed', 
sf Conf i g : : get ( ' app_max_j obs_on_catego ry ' ) ) ) -> 

with(' response ')->checkElement(' .jobs tr' , 
sf Conf i g : : get ( ' app _max_j obs_on_catego ry ' ) ) -> 

info(' 1.4 - The job listed is paginated' )-> 

wi th( ' response ' ) ->begi n() -> 

checkElementC .pagination desc' , '/32 jobs/')-> 

checkElement(' .pagination desc' , '#page l/2#')-> 

end()-> 

click('2')-> 

with(' request ')->begin() -> 
isParameter('page' , 2)-> 
end()-> 

with(' response')->checkElement(' . pagi nation_desc ' , '#page 2/2#') 



Deboguer les tests fonctionnels 

II arrive parfois qu'un test fonctionnel echoue. Comme Symfony simule 
un navigateur sans interface graphique, il peut devenir difficile de dia- 
gnostiquer rapidement l'origine du probleme. Heureusement, le fra- 
mework fournit la methode debug () pour imprimer le contenu et l'en- 
tete de la reponse sur la sortie standard. 

| $browser->with( ' response ' )->debug() ; 

La methode debug () peut etre inseree n'importe oil dans le bloc du testeur 
de la reponse. Son appel forcera l'arret immediat de l'execution du script. 

Executer successivement des tests 
fonctionnels 

La tache test: functional peut aussi etre utilisee pour lancer tous les 
tests fonctionnels d'une meme application. 

j $ php symfony test: functional frontend 

La tache affiche en sortie une ligne de resultat pour chaque fichier teste. 



~/work/jobeet $ ./symfony test: functional frontend 






ok 




ok 






WEEEmBSSsm 1 


-/work/jobeet S | 



Figure 9-2 

Resultat d'execution des tests fonctionnels 
de I'application « frontend » 



Executer les tests unitaires et fonctionnels 

II est bien evidemment possible d'executer tous les tests unitaires et 
fonctionnels d'une application. C'est en effet la tache test: all qui a le 
role de lancer a la suite tous les fichiers de tests et de generer en sortie un 
rapport pour chacun d'eux. 

| $ php symfony test: all 



-/work/jobeel i ./symfony test:all 

functional/frontend/categoryActionsTest ok 

functional/f rontend/jobActionsTest ok 

unit/JobeetTest ok 

uni t/model/ J obeet JobTest ok 

Alt tests successful. 
Files-4, Tests=39 
~/work/jobeet S | 



:s-39 
Si 



Figure 9-3 

Resultat d'execution 
de tous les tests de Jobeet 



En resume... 

Ce chapitre acheve le tour de presentation des outils de tests de Sym- 
fony. Desormais, il sera delicat de trouver un pretexte pour ne pas tester 
votre application ! Grace a lime et au framework de tests fonctionnels, 
Symfony apporte des outils puissants pour realiser l'ecriture de tests avec 
peu d 'effort. 

Pour l'instant, les tests fonctionnels ont ete relativement survoles, c'est 
pourquoi de nouveaux seront ecrits au cours du projet a chaque fois que 
de nouvelles fonctionnalites seront implementees ; ils seront l'occasion 
de decouvrir de nouveaux atouts du framework de test. 

Le chapitre suivant aborde une fonctionnalite essentielle de Symfony : le 
framework de formulaires. . . 
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symfony 



chapitre 




GET/frontend_dev.php/job/new 
$this->form = new JobeetJobFormQ; 



I Affichage du formulaire 



Post a Job 

Category id ■ Dc5 , sn ; j 

Typ» | fuHttmt 
Company 

IM 



' CHoose File ) no file selected 



Post a Job 

C*t»9t>ry id | Duly. «j 

Type [ Fu)IBm « p 

Company Required. 



Logo 



newSuccess 



<?php echo $form ?> 



POST /frontend_dev.php/job 
$this->form->bind($requGst->getParametGr{$form->getNamG())). 



2 Soumission du formulaire 



7\ 



if ($this->form->isValid()) 



Formulaire valide Formulaire invalide 




$this->form->save(); 

$this->redirect($this->generateUrl('job_show', $job)) 
GET/frontend_dev.php/job/TOKEN 



3 Previsualisation de I'offre 



showSuccess 



Accelerer la gestion 
des formulaires 



MOTS-CLES 



Les formulaires de saisie sont depuis toujours les principaux 
outils d'interaction avec l'utilisateur dans le but de recolter 
des informations. Bien qu'ils soient largement connus 
des developpeurs, leur manipulation n'en reste pas moins 
difficile et est souvent a l'origine de nombreuses failles 
de securite du systeme d'information. 

Ce chapitre montre comment Symfony simplifie grandement 
tant la creation et la validation des formulaires que leur 
traitement automatique. 



► Formulaires 

► Validation des donnees 
utilisateurs 

► Securite contre les failles CSRF 



Ce dixieme chapitre aborde l'une des principales grandes nouveautes de 
Symfony, apparue depuis la version 1.1 et enrichie dans cette nouvelle 
version. II s'agit en effet du framework interne de creation et de valida- 
tion des formulaires. Celui-ci simplifie la gestion des formulaires web en 
remplissant lui-meme les taches de generation, de controle d'integrite 
des donnees, de traitement automatique de ces dernieres lorsqu'elles sont 
validees, et de securite. 



A la decouverte des formulaires avec Symfony 

N'importe quel site Internet possede des formulaires. Cela va bien sur du 
simple formulaire de contact aux plus complexes composes d'une pleiade 
de champs divers et varies. Pour un developpeur, ecrire des formulaires 
est aussi l'une des taches les plus rebarbatives, les plus ardues et aussi les 
plus fastidieuses. Cette tache necessite en effet d'ecrire le code HTML 
du formulaire, puis d'implementer les regies de validation pour chaque 
champ, de traiter les valeurs pour les sauvegarder en base de donnees, 
d'afficher les messages d'erreur, de repeupler le formulaire en cas 
d'erreur, et bien plus encore. . . 

Bien evidemment, au lieu de reinventer la roue a chaque fois, Symfony 
fournit un framework dedie aux formulaires afin d'en simplifier leur ges- 
tion. Celui-ci se compose en trois parties distinctes : 

• la validation : le sous-framework de validation contient toutes les 
classes necessaires a la validation des entrees (entiers, chaines de 
caracteres, adresses e-mail, dates...) ; 

• les widgets : le sous-framework de widgets possede quant a lui les 
classes utiles a la generation du code HTML de chaque champ du 
formulaire (input, textarea, select...) ; 

• les formulaires : les classes du sous-framework de formulaires repre- 
sentent les formulaires concus a partir des widgets et des validateurs, 
et fournissent les methodes pour faciliter leur gestion. Chaque champ 
du formulaire dispose de son propre widget et de son ou ses propres 
validateurs. 

Les formulaires de base 

Dans Symfony, un formulaire n'est ni plus ni moins qu'une classe dans 
laquelle sont declares les champs. Chaque champ possede un nom, un 
widget et un ou plusieurs validateurs. Ainsi, un simple formulaire de 
contact peut etre defini d'apres la classe ContactForm suivante. 



<?php 



class ContactForm extends sfForm 
{ 

public function configure() 
{ 

$thi s->setWidgets(array( 

'email' => new sfWi dgetFormlnputC) , 
'message' => new sfWi dgetFormTextareaO , 

)); 

$thi s->setVal i dators(array( 

'email' => new sfVal i datorEmai 1 () , 

'message' => new sfValidatorString(array('max_length' => 

255)), 

)); 

} 

} 

Les champs du formulaire sont tous declares dans la methode 
configure() de la classe au moyen des methodes setWidgetsO et 
setVal idators(). 

Le framework de formulaires est par defaut livre avec un certain nombre 
de widgets et de validateurs prets a l'emploi. L'API les decrit tous tres 
largement en indiquant pour chacun toutes les options, erreurs et mes- 
sages d'erreur par defaut. 

Les noms des classes de widgets et de validateurs sont eux aussi tres expli- 
cites. Le champ email sera rendu par une balise HTML <input> 
(sfWidgetFormlnput) et valide comme une adresse e-mail 
(sfVali datorEmai l). Le champ message quant a lui sera rendu sous la 
forme d'une balise HTML <textarea> (sfwidgetFormTextarea). Sa 
valeur doit etre une chaine de caracteres d'une longueur strictement infe- 
rieure ou egale a 255 caracteres. Par defaut, tous les champs sont consi- 
dered comme obligatoires car la valeur par defaut de l'option requi red est 
true. Ainsi, la definition de la regie de validation du champ email est 
equivalente a new sfVal i datorEmai 1 (array (' requi red ' => true)). 

Un formulaire peut egalement etre fusionne avec un autre en utilisant la 
methode mergeFormO, ou bien embarquer un autre formulaire imbrique 
grace a la methode embed Form(). 

$thi s->mergeForm(new AnotherFormO) ; 

$thi s->embedForm( ' name ' , new AnotherFormO); 



Les formulaires generes par les taches Doctrine 

La plupart du temps, un formulaire a pour vocation d'etre serialise en 
base de donnees. Symfony connait deja tout du modele de base de don- 
nees, ce qui lui permet d'automatiser la generation de formulaires bases 
sur ces informations. En fait, lorsque la tache doctrine: build-all a ete 
executee au chapitre 3, Symfony a automatiquement fait appel a la tache 
doctri ne : bui ld-forms. 

$ php symfony doctrine: bui ld-forms 

La tache doctrine: bui ld-forms genere les classes de modele des formu- 
laires dans le repertoire lib/form/. Lorganisation de ces fichiers generes 
est semblable a celle de 1 i b/model /. Chaque classe de modele possede une 
classe de formulaire associee. Cette derniere est vide par defaut puisqu'elle 
herite des proprietes et des methodes de la superclasse de base qui contient 
l'ensemble de la configuration du formulaire. La classe JobeetDobForm est 
un exemple de formulaire Doctrine lie au modele JobeetJob. 

Contenu du fichier lib/form/doctrine/JobeetJobForm.class.php 

1 class JobeetJobForm extends BaseJobeetJobForm 
{ 

public function configureO 

{ 

} 

} 

C'est en parcourant les fichiers generes du repertoire lib/form/ 
doctrine/base/ que Ton decouvre des exemples etonnants d'usage des 
widgets et des validateurs natifs de Symfony. 

Personnaliser le formulaire d'ajout ou de modification 
d'une offre 

Le formulaire des offres est l'exemple parfait pour apprendre a person- 
naliser des classes de formulaires. Afin de garantir une meilleure com- 
prehension du processus de personnalisation, ce dernier sera presente pas 
a pas dans les prochaines sections. La premiere etape consiste a changer 
le lien « Post a job » du layout afin de controler les modifications directe- 
ment dans le navigateur. 

Code a placer dans le fichier apps/frontend/templates/layoutphp 

I <a href="<?php echo url for('@job new') ?>">Post a Job</a> 



L'objectif suivant presente la maniere de retirer des champs d'un formu- 
laire autogenere. 

Supprimer les champs inutiles du formulaire genere 

Par defaut, les formulaires Doctrine affichent tous les champs pour 
chaque colonne d'une table de la base de donnees. Or, pour le formulaire 
de creation d'offre d'emploi, certaines valeurs de la table jobeet_job ne 
doivent pas etre editees par l'utilisateur final. II faut done retirer du for- 
mulaire leur champ associe. La manipulation est triviale : II s'agit tout 
simplement de supprimer ces champs directement dans la methode 
configureO du formulaire comme le montre l'exemple ci-dessous. 

Contenu du fichier lib/form/doctrine/JobeetiobForm.class.php 

class JobeetJobForm extends BaseJobeetJobForm 
{ 

public function configureO 
{ 

unset ( 

$this['created at'] , $thi s[' updated at'] , 
$this[' expires at'] , $this['is activated'] 

); 

} 

} 

Supprimer un champ avec unset () revient a supprimer aussi bien son 
widget que son validateur. La syntaxe presentee ci-dessus peut paraitre 
exotique et surprenante a premiere vue. Comment un objet peut-il se 
comporter comme un tableau ? La reponse se trouve dans la declaration 
de la classe sfForm. Celle-ci implemente effectivement l'interface 
ArrayAccess de la SPL de PHP 5, en redefinissant les quatre methodes 
de cette derniere. Cette syntaxe a l'avantage d'etre a la fois plus simple et 
plus familiere pour les developpeurs PHP. 

Redefinir plus precisement la configuration d'un champ 

La configuration d'un formulaire doit parfois etre plus precise que celle 
qui a ete generee par l'analyse interne du modele de la base de donnees. 
Par exemple, la colonne emai 1 est declaree comme etant un varchar dans 
le schema, mais sa valeur doit, comme son nom l'indique, etre validee 
comme une veritable adresse de courrier electronique. II en va de meme 
pour le type d'offre. Ce champ est defini comme un varchar, mais dans 
la realite, son widget associe se presentera sous la forme d'une liste 
deroulante de choix predefinis. 



Utiliser le validateur sfValidatorEmail 

La breve introduction precedents explique clairement que la valeur du 
champ emai 1 doit etre acceptee uniquement si son format correspond a 
celui d'une adresse electronique valide. Heureusement, Symfony fournit 
un validateur pret a l'emploi pour remplir cette tache. II suffit done sim- 
plement de surcharger la configuration du champ email en lui appli- 
quant ce nouveau validateur sfValidatorEmail. 

Definition du validateur sfValidatorEmail pour le champ email dans le fichier lib/ 
form/doctrine/JobeetJobForm.class.php 

i public function configure() 
{ 

// ... 

$this->validatorSchema['email '] = new sfVal i datorEmai 1 () ; 

} 

Remplacer le champ permettant le choix du type d'offre par une 
liste deroulante 

Bien que le type de la colonne type de la table jobeet_job est un varchar, 
la valeur de ce champ doit etre restreinte a une liste predefinie de choix : 
« full time », « part time » ou bien « freelance ». Le widget le mieux adapte 
pour ce cas de figure est sans aucun doute une liste deroulante identifiee 
par une balise HTML <select>. Une liste de boutons radio ferait egale- 
ment tres bien l'affaire, du fait qu'il y a peu de choix possibles. 

Definir la liste des valeurs autorisees 

La premiere etape consiste tout d'abord a definir la liste des choix possi- 
bles sous la forme d'un simple tableau associatif PHP. Lendroit le plus 
approprie pour etablir celle-ci n'est pas forcement la classe du formulaire 
mais le modele, et plus exactement la classe JobeetDobTable comme le 
montre l'exemple suivant. 

Declaration de la liste des types de poste dans le fichier lib/model/doctrine/ 
JobeeUobTable.class.php 

class Jobeet JobTabl e extends Doctri ne_Tabl e 
{ 

static public $types = array( 

'full-time' => 'Full time', 

'part-time' => 'Part time', 

'freelance' => 'Freelance', 

); 



public function getTypes() 
{ 

return sel f : : $types ; 

} 

// ... 

} 

Le tableau associatif Stypes possede en cle la valeur a sauvegarder en 
base de donnees, done la valeur de chaque noeud <option> de la liste 
deroulante, associee a la chaine a afficher en guise de label dans chaque 
balise <option>. 

Implementer le widget sfWidgetFormChoice 

La seconde etape de personnalisation du champ type consiste mainte- 
nant a instancier un objet sfWidgetFormChoice, auquel est attribue la 
liste des types predefinis pour remplir la liste deroulante. 

$thi s->wi dgetSchema[ ' type ' ] = new sfWi dgetFormChoi ce(array( 
'choices' => Doctrine: :getTable(' JobeetJob')->getTypes() , 
'expanded' => true, 

)); 

sfWidgetFormChoice represente un widget de choix qui peut etre rendu 
par un autre widget different selon la definition de ses options de confi- 
guration (expanded ou multiple). La liste ci-dessous fait le bilan de 
toutes les possibilites de configuration de ce widget, et la forme qu'il 
prendra lorsqu'il sera rendu dans sa version HTML. 

• Liste deroulante (<select>) : array('multiple' => false, 
'expanded' => false) 

• Liste deroulante multiple (<select multiple="multiple">) : 
array('multiple' => true, 'expanded' => false) 

• Liste de boutons radio : array (' multiple' => false, 'expanded' => 
true) 

• Liste de cases a cocher : array (' multiple' => true, 'expanded' => 
true) 

Pour forcer la selection d'un bouton radio par defaut (full-time par 
exemple), il suffit de changer la valeur par defaut dans le schema de des- 
cription de la base de donnees. 

Valider la valeur choisie par I'utilisateur avec sfValidatorChoice 

La derniere etape de personnalisation concerne desormais la validation 
de la donnee transmise par ce champ. Contrairement a ce qu'on pourrait 
croire, le fait d'utiliser une liste deroulante pour conditionner les choix 
possibles ne garantit en rien la fiabilite de la valeur soumise. En effet, 



n'importe qui peut soumettre une valeur non valide. Un hacker, par 
exemple, outrepassera facilement la liste deroulante en utilisant des 
outils comme Curl (Client URL Request Library, permettant de recu- 
perer le contenu d'une ressource accessible a une URL) ou la celebre 
Firefox Web Developper Toolbar. Le code qui suit ajoute un validateur 
sfValidatorChoice qui permet de controler que la valeur saisie corres- 
pond bien a l'une des valeurs autorisees du widget. 

$this->validatorSchema['type'] = new sfVal i datorChoi ce(array( 

'choices' => array_keys(Doctri ne : :getTable(']obeetJob')- 
>getTypes()) , 

)); 

La configuration du validateur est tres aisee puisqu'il s'agit de fournir 
une liste des valeurs autorisees a l'option choices de ce dernier. C'est 
exactement ce que realise la fonction array_keys() de PHP qui retourne 
un tableau classique dont les valeurs sont cette fois-ci les cles du tableau 
$types definis plus haut. 

Personnaliser le widget permettant I'envoi du logo associe a une 
offre 

Le champ logo stocke la valeur du nom de fichier du logo associe a 
l'offre. Or, pour permettre a l'utilisateur d'ajouter un logo a son offre, le 
widget du champ logo doit imperativement etre transforme en un 
champ input de type file. Bien sur, chaque fichier transmis doit egale- 
ment etre controle pour eviter le telechargement de documents poten- 
tiellement dangereux pour l'application. De ce fait, le fichier telecharge 
devra imperativement etre une image. 

Implementer le widget sfWidgetFormlnputFile 

Dans Symfony, un champ de telechargement de fichier est declare au 
moyen du widget sfWidgetFormlnputFile. Ce dernier retourne le code 
HTML d'un champ <input> de type file qui permet a l'utilisateur de 
proposer des fichiers a telecharger depuis le disque dur de son ordinateur. 

$this->widgetSchema['logo'] = new sfWidgetFormInputFile(array( 
'label' => 'Company logo', 

)); 

II ne reste enfin qua specifier un validateur pour controler automatique- 
ment les caracteristiques du fichier transmis. C'est le role du validateur 
sfValidatorFile. 



Valider les fichiers avec sfValidatorFile 



En proposant a l'utilisateur d'envoyer un fichier pour illustrer son offre, 
c'est aussi la une ouverture du serveur aux fichiers potentiellement mal- 
veillants. C'est pour cette raison qu'il faut s' assurer que chaque fichier 
transmis est sain et ne comporte pas de risque pour le systeme d'infor- 
mation qui l'accueille. Dans le cas de Jobeet, les fichiers autorises sont 
uniquement des images, ce qui limite considerablement les risques 
d'infection du systeme. Neanmoins, les images ont des caracteristiques 
propres, comme l'extension ou le type de contenu, qui sont faciles a 
valider. Pour ce faire, Symfony met a disposition le validateur 
sfValidatorFile qui contient par defaut une configuration specifique 
pour la validation des images. 

$this->validatorSchema['logo'] = new sfValidatorFile(array( 
' requi red' => false, 

'path' => sfConfig: : get( ' sf_upload_di r ' ) . '/jobs' , 

'mime types' => 'web images' , 

)); 

Le code ci-dessus presente une option mime_types avec la valeur 
web_i mages. II s'agit en fait de la definition de la configuration du valida- 
teur pour le controle des fichiers d'images. 

Que se passe-t-il concretement lorsqu'un utilisateur soumet un fichier 
depuis le formulaire ? Tout d'abord, le validateur sfValidatorFile 
s'assure que le fichier transmis est bien une image au format web. II le 
renomme ensuite avec un nom arbitraire et unique afin de supprimer les 
espaces et autres caracteres accentues. Puis, il copie ce fichier dans le 
repertoire defini par l'option path avant de mettre finalement a jour la 
valeur de la colonne 1 ogo avec le nouveau nom du fichier. 

Implementer I'affichage du logo dans le template 

Sachant que le validateur sauvegarde le chemin relatif dans la base de 
donnees, le chemin utilise dans le template showSuccess.php doit etre 
edite en consequence. 

Code a remplacer dans le template apps/frontend/modules/job/template/ 
showSuccess.php 

<img src="/uploads/jobs/<?php echo $ job->getl_ogo() ?>" 
alt="<?php echo $job->getCompany() ?> logo" /> 

Si une methode generateLogoFilenameO existe dans le modele, elle sera 
automatiquement appelee par le validateur afin de redefinir le processus 
natif de generation du nom de fichier. Cette methode prend un objet de 
type sfValidatedFile comme argument. 



Remarque Creation du repertoire 
d'upload des logos 

La creation du repertoire web/uploads/ 
jobs/ n'est pas geree par Symfony. Cela doit etre 
fait manuellement en s'assurant que le repertoire 
possede les droits d'ecriture necessaires. 
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Modifier plusieurs labels en une seule passe 

Symfony attribue par defaut un label (balise HTML <label>) specifique 
a chaque champ du formulaire, en se basant sur leur nom respectif. Bien 
evidemment, chaque valeur de label est entierement personnalisable, et 
peut etre specifiee soit dans la configuration du widget grace a l'option 
1 abel , soit directement et pour plusieurs champs a la fois grace a la 
methode setl_abels(). La premiere methode a ete presentee lors de la 
configuration du widget du champ logo quelques lignes plus haut. La 
seconde quant a elle est expliquee dans le code ci-dessous. 

$thi s->wi dgetSchema->set Label s (array ( 
'category_id' => 'Category', 
' i s_publ i c ' => ' Pub! i c? ' , 

' how_to_apply ' => 'How to apply?', 

)); 

La methode setl_abels() prend un tableau associatif en parametre dont 
la cle correspond au nom du champ, et la valeur a la chaine qui doit etre 
affichee dans la balise <label> generee. 

Ajouter une aide contextuelle sur un champ 

De la meme maniere que le label d'un champ peut etre surcharge, Sym- 
fony propose un moyen d'ajouter une aide contextuelle aux champs du 
formulaire. Lobjectif de cette derniere est d'apporter une information a 
la fois plus significative et plus pertinente que le label du champ lui- 
meme. Par exemple, le champ is_public du formulaire en necessite une. 

$this->widgetSchema->setHelp('is_public' , 'Whether the job can 
also be published on affiliate websites or not.'); 

Dans ce cas precis, cette aide indique a l'utilisateur s'il souhaite publier ou 
non son offre sur les sites web partenaires pour quelle ait plus de visibilite. 

Presentation de la classe finale de configuration du formulaire 
d'ajout d'une offre 

Apres toutes les modifications apportees dans ces dernieres sections, la 
classe JobeetJobForm est desormais la suivante. 

Contenu du fichier lib/form/doctrine/JobeetJobForm.class.php 

<?php 



class JobeetJobForm extends BaseJobeetJobForm 
{ 

public function configureQ 



{ 

unset( 

$thi s [ ' created_at ' ] , $thi s [ ' updated_at ' ] , 
$this['expi res_at'] , $thi s [ ' i s_acti vated ' ] 

); 



$thi s->validatorSchema[ 'email '] = new sfValidatorEmail () ; 

$this->widgetSchema['type'] = new sfWi dgetFormChoi ce(array( 
'choices' => Doctrine: :getTable(' JobeetJob')->getTypes() , 
'expanded' => true, 

)); 

$this->va"lidatorSchema['type'] = new 
sfVal i datorChoi ce(array ( 

'choices' => array_keys (Doctrine: :getTable(' JobeetJob ' ) - 
>getTypes()) , 

)); 



$this->widgetSchema['logo'] = new 
sfWidgetFormInputFile(array( 

'label' => 'Company logo', 

)); 



$thi s->wi dgetSchema->set Label s(array( 
' category_i d 1 => 'Category', 
'is_public' => 'Public?' , 

'how_to_apply' => 'How to apply?', 

)); 



$this->validatorSchema['logo'] = new sfVal i datorFi 1 e(array( 
' requi red ' => fal se , 

'path' => sfConfig: :get('sf_upload_di r') . '/jobs' , 

'mime_types' => ' web_i mages ' , 

)); 

$this->widgetSchema->setHelp('is_public' , 'Whether the job 
can also be published on affiliate websites or not.'); 
} 

} 

II est temps de decouvrir comment sont rendus les formulaires dans les 
templates, et de quelle maniere leur habillage peut etre personnalise pour 
repondre aux besoins de la maquette graphique de l'application. 



Manipuler les formulaires directement dans 
les templates 



Remarque La feuille de style des offres 

Si la feuille de style job . ess n'a pas encore ete 
ajoutee aux templates newSuccess . php et 
edi tSuccess . php, e'est le moment de le faire 
pour ces derniers en utilisant <?php 
use_stylesheet(' job. ess') ?> 



Generer le rendu d'un formulaire 

Maintenant que la classe du formulaire est personnalisee, il ne reste plus 
qua l'afficher. Dans Jobeet, le template du formulaire est exactement le 
meme, que l'on veuille creer une nouvelle offre ou que Ton souhaite en 
editer une existante. En fait, les deux fichiers newSuccess. php et 
edi tSuccess . php sont sensiblement similaires. 

Extrait du fichier apps/frontend/modules/job/templates/newSuccess.php 

<?php use_styl esheet( ' job. ess') ?> 
<hl>Post a Job</hl> 

<?php include_partial ('form' , array( ' form ' => $form)) ?> 

Le formulaire est lui-meme rendu dans le template partiel _form.php. 
L' application Jobeet necessite un rendu legerement different pour ce for- 
mulaire, e'est pourquoi le contenu du fichier _form.php doit etre rem- 
place par le code suivant. 

Contenu du fichier apps/frontend/modules/job/templates/_form.php 

<?php include stylesheets for form($form) ?> 
<?php include javascripts for form($form) ?> 

<?php echo form tag for($form, '@job') ?> 

<table id="job_form"> 
<tfoot> 
<tr> 

<td colspan="2"> 

<input type="submit" val ue="Previ ew your job" /> 
</td> 
</tr> 
</tfoot> 
<tbody> 

<?php echo $form ?> 
</tbody> 
</table> 
</form> 

Les helpers include_stylesheets_for_form() et 

include_javascripts_for_form() importent les fichiers CSS et JavaS- 
cript necessaires au bon fonctionnement de certains widgets du formu- 
laire. Bien que le formulaire d'offre ne necessite ni CSS ni JavaScript 
particulier, la bonne pratique consiste a toujours conserver ces helpers 
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dans le template a titre preventif. Ce sera, en effet, un reel gain de temps 
le jour ou de veritables widgets specifiques seront integres au formulaire. 
L'approche pragmatique reste bien souvent la meilleure ! 

Le helper form_tag_forO se charge de generer la balise <form> pour le for- 
mulaire et la route donnes. D'autre part, il fixe la methode a POST ou PUT 
selon que l'objet associe au formulaire est nouveau ou non. Enfin, il prend 
garde a bien implementer l'attribut special multipart si le formulaire con- 
tient au moins un widget de transfert de fichier. Dans le code precedent, le 
formulaire est entierement rendu grace a l'instruction <?php echo 
$form ?>. La structure du langage echo appelle implicitement la methode 

toStringO du formulaire qui genere tous les widgets, labels, messages 

d'erreur et autres informations d'aide declares dans la classe Jobeet JobForm. 

Cependant, la plupart des formulaires que Ton trouve sur l'lnternet sont 
tres specifiques et peuvent etre, pour certains, relativement complexes a 
mettre en page. La section suivante apporte la documentation de base 
pour generer un formulaire Symfony a la main, champ par champ. 

Personnaliser le rendu des formulaires 

Par defaut, l'instruction <?php echo $form ?> genere le formulaire sous 
la forme d'un tableau HTML ou chaque ligne correspond a un widget. 
Or, la plupart du temps, le layout d'un formulaire se revele different et 
plus complexe selon l'aspect general souhaite. Par exemple, il sera parfois 
necessaire d'ajouter des balises <fieldset> pour separer les blocs de 
meme nature ou bien simplement pour afficher deux champs particuliers 
l'un a cote de l'autre. 

Decouvrir les methodes de l'objet sfForm 

L'objet de formulaire fournit plusieurs methodes utiles pour faciliter la 
personnalisation du rendu afin de ne pas etre contraint uniquement a 
une structure en tableau. Le tableau ci-dessous resume les principales 
methodes qu'il est possible d'utiliser. 



Tableau 10-1 Liste des methodes utiles au rendu de l'objet sfForm 



Methode 




renderO 


Genere le formulaire (equivalent pour echo Sform) 


renderHiddenFieldsO 


Genere les champs caches 


hasErrorsO 


Retourne true si le formulaire a des erreurs 


hasGlobal Errors 0 


Retourne true si le formulaire a des erreurs globales 


getGlobalErrorsO 


Retourne un tableau d'erreurs globales 


renderClobal ErrorsQ 


Genere les erreurs globales 



E 



Comprendre et implementer les methodes de I'objet sfFormField 

Au meme titre que pour I'objet sfForm, chaque champ peut etre rendu 
individuellement grace aux methodes de la classe sfFormField. Dans un 
template, himporte quel champ du formulaire peut etre recupere unitai- 
rement grace a la syntaxe ArrayAccess de I'objet sfForm. Par exemple, 
$form[' company'] retourne I'objet sfFormField correspondant au champ 
company du formulaire. Le tableau qui suit dresse une liste des methodes 
de rendu applicables a n'importe quel champ d'un formulaire. 

Tableau 10-2 Liste des methodes utiles au rendu de I'objet sfFormField 



renderRowO 


Genere la ligne complete du champ 


renderO 


Retourne le code HTML du widget 


renderLabel () 


Retourne le code HTML de la balise <1 abel > 


renderError() 


Genere le message d'erreur du champ 


renderHel p() 


Genere I'aide du champ 



L'exemple de code suivant est une syntaxe equivalente a echo Sform. 

<?php foreach ($form as Swidget): ?> 
<?php echo $wi dget->renderRow() ?> 
<?php endforeach; ?> 

Cet autre bout de code illustre la maniere de generer individuellement 
un champ de formulaire complet dans un template au moyen des 
methodes de I'objet sfFormField. 

<div class="form_field"> 

<?php echo $form['company' ]->renderErrorO ; ?> 

<?php echo $form['company']->renderLabe1 () ; ?> 

<?php echo $form['company']->render() ; ?> 

<div class="form_field_help"> 

<?php echo $form['company']->renderHe1p() ; ?> 

</di v> 
</di v> 



Manipuler les formulaires dans les actions 

Les parties precedentes ont montre comment, dans Symfony, un formu- 
laire est declare, puis configure et enfin rendu dans un template. La der- 
niere etape consiste done a expliquer de quelle maniere un formulaire est 
rendu dynamique dans les actions d'un module. 
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Decouvrir les methodes autogenerees du module job 
utilisant les formulaires 

Pour l'instant, Jobeet dispose d'un formulaire capable de gerer la creation 
et l'edition d'une offre. Ce dernier se resume toujours a une classe de 
configuration des champs ainsi qua un template partiel pour l'afficher. II 
est desormais temps de le mettre en ceuvre au sein des actions. 

Le formulaire des offres est actuellement gere par cinq methodes des 
actions du module job : 

• new : affiche un formulaire vide pour creer une nouvelle offre ; 

• edit : affiche un formulaire prerempli pour editer une offre existante ; 

• create : cree la nouvelle offre a partir des donnees saisies par 
l'utilisateur ; 

• update : met a jour l'offre existante a partir des donnees saisies par 
l'utilisateur ; 

• processForm : appelee par create et update, cette methode se charge 
de traiter le formulaire (validation, repeuplement du formulaire et 
serialisation vers la base de donnees). 

Tous les formulaires decrivent le meme cycle de vie comme l'illustre le 
schema suivant. 



E 



< 



GET/frontend_dev.php/job/new 
$this->form = new JobeetJobFormO; 



j Affichage du formulaire 



Post a Job 

Category id [ rjesig 



Post a Job 

Category id | Design 



newSuccess 
<?php echo $form ?> 



Typ. I Ml time «j 

Company 

Logo f choose File ) no file selected 

un 



Company Required. 
Logo 



' Oioosente ' no file selected 



POST /frontend_dev.php/job 
$this->form->bind($request->getParameter($form->gGtName())), 



2 Soumission du formulaire 



if ($this->form->isValid()) 



Formulaire valide H Formulaire invalide 



$this->form->save(); 

$this->redirect($this->generatGUrl('job_show', $job)); 
GET/frontend_dev.php/job/TOKEN 



3 Previsualisation de l'offre 



showSuccess 



Figure 10-1 

Cycle de vie des formulaires 
dans Symfony 
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Traiter les formulaires dans les actions 



Les sections suivantes s'interessent a la mise en pratique du formulaire 
des offres dans les actions. Elles presentent comment le framework 
Symfony simplifie la manipulation du formulaire tout au long de son 
cycle de vie en quelques lignes de code elementaires. La premiere etape 
consiste a reduire la methode de traitement du formulaire 
processFormC). 

Simplifier le traitement du formulaire dans le module job 

Au chapitre 5, une route Doctrine dediee au module job a ete creee. De ce 
fait, le code de gestion du formulaire peut etre simplifie a celui ci-dessous : 

Contenu du fichier apps/frontend/modules/job/actions/actions.class.php 

public function executeNew(sfWebRequest Srequest) 
{ 

$this->form = new JobeetJobFormO ; 

} 

public function executeCreate(sfWebRequest Srequest) 
{ 

$this->form = new JobeetJobFormO ; 
$this->processForm($request, $this->form) ; 

$this->setTemplate('new') ; 

} 

public function executeEdi t(sfWebRequest Srequest) 
{ 

$this->form = new Jobeet3obForm($this->getRoute()- 
>getObject()) ; 

} 

public function executeUpdate(sfWebRequest Srequest) 
{ 

$this->form = new Jobeet3obForm($this->getRoute()- 
>getObject()); 

$this->processForm($request, $this->form) ; 

Sthis->setTempl ate ('edit') ; 

} 

public function executeDel ete(sfWebRequest Srequest) 
{ 

Srequest->checkCSRFProtection() ; 

Sjob = Sthis->getRoute()->getObject() ; 
$job->delete() ; 

$this->redi rect(' job/index') ; 

} 



protected function processForm(sfWebRequest $request, sfForm 

$form) 

{ 

$form->bind( 

$request->getParameter($form->getName()) , 
$request->getFiles($form->getName()) 

); 

if C$form->isVa1id()) 
{ 

$job = $form->save() ; 

$this->redirect($this->generatellrl ('job show' , $job)) ; 

} 

} 

Comprendre le cycle de vie du formulaire 

Quelques explications s'imposent pour comprendre tout le sens de ce 
code. Que se passe-t-il lorsque l'utilisateur cree ou edite une offre ? 

Lorsque celui-ci navigue sur la page /job/new, une nouvelle instance du for- 
mulaire est creee et passee au template (action new). Puis, des que l'utilisa- 
teur soumet le formulaire (action create), ce dernier est initialise avec les 
valeurs qu'il a saisies et le processus de validation est mis en route. 

A partir du moment ou le formulaire est initialise, il est possible de con- 
troler sa validite a l'aide de la methode isValidO. Si le formulaire est 
valide (isValidO retourne true), alors la nouvelle offre est enregistree 
en base de donnees ($form->save()) et l'utilisateur est automatiquement 
redirige vers la page de previsualisation. Dans le cas contraire, le tem- 
plate newSuccess . php est reaffiche avec les valeurs saisies ainsi que les 
messages d'erreur generes. 

La modification d'une offre existante est sensiblement la meme. La seule 
difference entre les actions new et edit reside dans le fait que l'objet 
JobeetJob a modifier est passe comme premier argument du construc- 
teur du formulaire. II servira alors a definir les valeurs par defaut de 
chaque widget dans le template. Lensemble de ces valeurs correspond a 
un objet pour les formulaires Doctrine, alors qu'il s'agit d'un simple 
tableau pour les formulaires traditionnels. 

Definir les valeurs par defaut d'un formulaire genere par Doctrine 

II existe deux manieres de definir les valeurs par defaut d'un formulaire 
de creation. La premiere consiste a declarer les valeurs dans le schema de 
definition de la base de donnees, tandis que la seconde invite a passer un 
objet JobeetJob premodifie au constructeur du formulaire. 



ASTUCE Changer le template par defaut 
d'une action 

La methode setTempl ate() change le tem- 
plate utilise par defaut pour une action donnee. Si 
le formulaire soumis n'est pas valide, les methodes 
create et update utilisent le meme template 
dans la mesure ou les actions new et edi t reaffi- 
chent le formulaire avec ses messages d'erreur. 



187 



Le code ci-dessous initialise la valeur par defaut (full-time) du widget 
type du formulaire a l'aide d'un objet prerempli. 

Redefinition de la methode executeNew() du fichier apps/frontend/modules/job/ 
actions/actions.class.php 

public function executeNew(sfWebRequest Srequest) 
{ 

$job = new JobeetJobO; 
$job->setType(' full -time') ; 

$this->form = new Jobeet]obForm($job) ; 

} 

Quand le formulaire est initialise avec les valeurs postees, les valeurs par 
defaut sont automatiquement remplacees par les donnees saisies. En effet, 
en cas d'erreur de validation, ces dernieres servent a repeupler le formulaire. 

Proteger le formulaire des offres par ('implementation 
d'un jeton 

A present, tout doit fonctionner correctement mais il reste encore un 
dernier point a regler : le jeton correspondant ici au champ token. Pour 
le moment, ce dernier doit etre rempli manuellement par l'utilisateur. 
Bien evidemment, le principe du jeton, c'est d'etre genere automatique- 
ment lorsque la nouvelle offre est creee. Ce n'est done plus a l'utilisateur 
de fournir lui-meme cette donnee. 

Generer le jeton automatiquement a la creation 

Le moyen le plus simple et le plus sur pour y parvenir est de realiser la 
generation du jeton dans la methode save() de la classe JobeetJob. La 
valeur du jeton doit etre definie juste avant que l'objet soit serialise en 
base de donnees. 

Surcharge de la methode save() du fichier // lib/model/doctrine/ 
JobeeUob.class.php 

public function save(Doctri ne_Connection Scon = null) 
{ 

// ... 

if (!$this->getToken()) 
{ 

$this->setToken(shal($this->getEmail () . rand(lllll, 99999))) ; 

} 

return parent: : save($conn) ; 

} 



E 

Desormais, le champ token peut etre retire de la configuration du for- -8 
mulaire en toute securite. ^ 

_o 

'*-> 

Suppression du champ token dans le fichier lib/form/doctrine/ !> 
JobeeUobForm.class.php "Z 

t— 

IS* 

class JobeetJobForm extends BaseDobeet JobForm § 

{ f 

public function configure() 2 
{ 

unset( 

$thi s [ ' created_at ' ] , $thi s [ ' updated_at ' ] , 
$this['expi reseat'] , $thi s [ ' i s^acti vated ' ] , 
$this[' token'] 

); 

// ... 

} 



II ... 

} 



Redefinir la route d'edition de 1'offre grace au jeton 

Si Ton se souvient des cas d'utilisation du chapitre 2, une offre d'emploi 
est editable a condition que i'utilisateur connaisse le jeton associe. Pour 
le moment, il est tees facile d'editer ou de supprimer n'importe quelle 
offre en devinant seulement son URL. En effet, l'URL qui mene au for- 
mulaire d'edition repose sur le schema job/ID/edit ou la valeur de ID 
correspond a la cle primaire de 1'offre dans la base de donnees. 

Par defaut, une route sfDoctri neRouteCol lection compose les URLs a 
partir de la cle primaire, mais il est bien sur possible de remplacer cette 
derniere par n'importe quelle colonne unique en passant l'option col umn. 

Definition de la route job dans le fichier apps/frontend/config/routing.yml 

job : 

cl ass : sfDoctri neRouteCol 1 ecti on 

options: { model: JobeetJob, column: token } 

requirements: { token: \w+ } 

II faut remarquer au passage que la contrainte du parametre token a ete 
modifiee egalement pour correspondre a n'importe quelle chaine de 
caracteres. En effet, le format obligatoire par defaut de l'option col umn 
doit etre un entier positif en guise de cle unique. 



189 



Desormais, toutes les routes relatives aux offres d'emploi, mis a part la 
route job_show_user, integrent le jeton. Par exemple, la route qui mene a 
l'edition d'une offre est formatee de la facon suivante : 

j http : //jobeet . 1 ocal host/job/TOKEN/edi t 

Enfin, il ne reste plus qua modifier le lien « Edit » du template 
showSuccess . php. 



Construire la page de previsualisation 

La page de previsualisation est exactement la meme que la page de con- 
sultation d'une offre. Grace au routage, si l'utilisateur arrive avec le bon 
jeton, ce dernier sera accessible dans le parametre token de la requete. 
D'autre part, si l'utilisateur entre avec une URL contenant le bon jeton, 
une barre d'administration sera ajoutee au-dessus de l'offre. II suffit alors 
tout simplement de modifier le debut du template showSuccess . php afin 
que celui-ci puisse accueillir la barre d'administration. Apres cela, le lien 
edi t situe en pied de page n'a plus qua etre retire. 

Code a ajouter au debut du fichier apps/frontend/modules/job/templates/ 
showSuccess.php 

<?php if ($sf_request->getParameter( ' token ' ) == $job- 
; >getToken()) : ?> 

<?php includejartial (' job/admin' , arrayCjob' => $job)) ?> 
<?php endif; ?> 

Letape suivante consiste a creer le template partiel _admin.php en lui 
ajoutant le contenu suivant. 

<!-- apps/f rontend/modules/job/templates/_admin.php --> 
<div id="job_actions"> 

<h3>Admi n</h3> 

<ul> 

<?php if (!$job->getIsActivated()) : ?> 

<lix?php echo link_to('Edit' , 'job_edit', $job) ?></li> 
<lix?php echo link_to(' Publish' , 'job_edit', $job) ?></li> 
<?php endif; ?> 

<lix?php echo link_to(' Delete' , ' job_del ete ' , $job, 
arrayC method' => 'delete', 'confirm' => 'Are you sure?')) ?></li> 
<?php if ($job->getIsActivated()) : ?> 
<li<?php $job->expiresSoon() and print 
' class="expi res_soon" ' ?» 



<?php if ($job->isExpired()) : ?> 

Expi red 
<?php else: ?> 

Expires in <strongx?php echo 

$job->getDaysBeforeExpires() ?></strong> days 
<?php endif; ?> 

<?php if ($job->expiresSoon()) : ?> 

- <a href="">Extend</a> for another <?php echo 
sfConfig: :get('app_active_days') ?> days 
<?php endif; ?> 
</li> 
<?php else: ?> 
<li> 

[Bookmark this <?php echo link_to('URL' , 'job_show', 

$job, true) ?> to manage this job in the future.] 

</li> 
<?php endif; ?> 
</ul> 
</di v> 

II y a beaucoup de code a etudier. Neanmoins la plupart de celui-ci est 
tres facile a comprendre. Afin de rendre le template plus lisible et com- 
prehensible, un certain nombre de methodes raccourcies a ete ajoute a la 
classe JobeetJob. 

Nouvelles methodes de la classe lib/model/doctrine/JobeetJob.class.php 

public function getTypeName() 
{ 

Stypes = Doctrine: :getTable(']obeetJob')->getTypes() ; 
return $thi s->getType() ? Stypes [$thi s->getType()] : ''; 

} 

public function isExpiredO 
{ 

return $thi s->getDaysBeforeExpi res() < 0; 

} 

public function expi resSoon() 
{ 

return $thi s->getDaysBeforeExpi res() < 5; 

} 

public function getDaysBeforeExpi res() 
{ 

return floor((strtotime($this->getExpi resAtO) - timeO) / 
86400) ; 
} 

La barre d'administration affiche les differentes actions en fonction du 
statut de l'offre d'emploi. 



Figure 10-2 

Etat de la barre 
d'administration 
I'une offre non active 



Admin Edit Publish Delete [Bookmark this URL to manage this job in the future.! 



SENSIO LABS 



Web Developer - full-time 



Figure 10-3 

Etat de la barre 
d'administration 
d'une offre active 



keywords (dry, country, position, ...) 



Admin Delete Expires in 29 days 



SENSIO LABS 



Web Developer - fuii-time 



La barre d'activation du second ecran sera mise en place des la prochaine 
section. 



Activer et publier une offre 



Preparer la route vers Taction de publication 

Dans la section precedente se trouve un lien pour publier une offre 
d'emploi. Celui-ci a besoin d'etre modifie pour pointer vers Faction 
publish. Au lieu de creer une nouvelle route, il suffit de configurer la 
route existante job comme le montre le code ci-dessous. 



Configuration de la route job dans le fichier apps/frontend/config/routing.yml 

job: 

class: sfDoctrineRouteCollection 
options : 

model : JobeetJob 

column: token 

object actions: { publish: put } 
requi rements : 

token : \w+ 

L'option object_actions prend un tableau des actions additionnelles 
pour l'objet donne. Ainsi, le lien de publication d'une offre peut desor- 
mais etre modifie. 



Extrait du contenu du fichier apps/frontend/modules/job/templates/_admin.php 

<li> 

<?php echo 1 i nk_to( 1 Publ i sh ' , ' job_put>1 i sh ' , $job, 
arrayC method' => 'put')) ?> 

</1i> 

Implementer la methode executePublish() 

La derniere etape consiste a creer 1' action executePublishO dans le 
fichier actions.class.php du module job. 

Methode executePublish() a ajouter au fichier apps/frontend/modules/job/actions/ 
actions.class.php 

public function executePublish(sfWebRequest Srequest) 
{ 

$request->checkCSRFProtection() ; 

$job = $this->getRoute()->getObject() ; 
$job->pub1 ish() ; 

$this->getUser()->setFlash('notice' , spri ntf ( ' Your job is now 
online for %s days.', sfConf i g : : get( ' app_acti ve_days ' ))) ; 

$this->redi rect($thi s->generateUrl ( ' job_show_user ' , $job)) ; 

} 

Le lecteur assidu aura remarque que le lien « Publish » est soumis a l'aide 
de la methode HTTP PUT. Pour simuler cette methode PUT, le lien est 
automatiquement converti en un formulaire quand on clique dessus 
grace au JavaScript. 

D'autre part, comme la protection CSRF (Cross- Site Request Forgeries) 
a ete activee pour Jobeet lors du premier chapitre, le helper 1ink_to() 
integre un jeton CSRF au lien, tandis que la methode 
checkCSRFProtectionO de l'objet requete s assure de sa validite au 
moment de son envoi. 

Implementer la methode publishO de l'objet JobeetJob 

La methode executePublishO du controleur utilise une nouvelle 
methode publishO appliquee sur l'objet JobeetJob. Celle-ci se resume 
simplement au code ci-dessous. 



Bonne pratique 

Precisions sur la faille de securite CSRF 

II s'agit d'une faille de securite tres repandue mais 
malheureusement tres rarement prise en compte 
dans le developpement d'applications. Cette faille 
profite de la confiance qu'a I'utilisateur dans les 
systemes d'authentification pour effectuer cer- 
taines actions a son insu. L'un des moyens les plus 
efficaces pour se proteger de ces attaquesreste 
('implementation d'un jeton, comme le fait le 
helper 1 i nk_to() par defaut. 



193 



Declaration de la methode publish () dans le fichier lib/model/doctrine/ 
JobeeUob.class.php 

j public function publishO 
{ 

$this->setIsActivated(true) ; 
$this->save() ; 

} 

La nouvelle fonctionnalite de publication d'offre d'emploi peut mainte- 
nant etre testee dans un navigateur. Neanmoins, il reste encore quelque 
chose a fixer : Les offres non activees ne doivent pas etre accessibles, ce 
qui signifie qu'elles ne doivent plus etre affichees sur la page d'accueil de 
Jobeet, et ne doivent pas non plus etre atteignables par leur URL. 

Empecher la publication et I'acces aux offres non actives 

Dans les precedents chapitres, une methode addActi veJobsQueryO avait 
ete creee pour restreindre un critere aux seules offres actives. II suffit 
alors d'editer et d'ajouter de nouvelles contraintes a la fin de la methode, 
comme le montre le code suivant. 

Methode addActiveJobsQueryO du fichier lib/model/doctrine/JobeetJobTable.dass.php 

public function addActi veJobsQuery(Doctri ne_Query $q = null) 
{ 

// ... 

$q->andWhere($alias . '. is activated = ?', 1); 

return $q; 

} 

C'est fini ! II ne reste plus qua tester dans le navigateur que l'ensemble 
se comporte correctement. Desormais, toutes les offres non actives ont 
disparu de la page d'accueil et ne sont plus accessibles en devinant leur 
URL. Elles restent en revanche atteignables si quelqu'un connaitle jeton 
de l'offre et s'en sert dans FURL. Dans ce cas precis, ce sera la page de 
previsualisation de l'offre et sa barre d'administration qui seront affi- 
chees a l'ecran. 

C'est l'un des principaux avantages du motif de conception MVC et de 
la refactorisation qui a ete realisee tout au long de ce parcours. Seule- 
ment un unique changement dans une seule methode a permis d'appli- 
quer la nouvelle contrainte sur l'ensemble de l'application. 



E 

Lorsque la methode getWithJobsO a ete creee, l'utilisation de la -S 
methode addActi veDobsQueryO a ete oubliee, ce qui signifie qu'il faille ^ 
l'editer et aj outer la nouvelle contrainte. v. 

.2 

class JobeetCategoryTable extends Doctri ne_Tabl e s 
{ £ 
public function getWith]obs() S 

{ f 
// ... s 



$q->andWhere('j. is activated = ?', 1) ; 

return $q->execute() ; 



En resume... 

Ce chapitre a aborde toute une serie de nouvelles informations, qui vous 
ont permis d'acquerir une meilleure connaissance du framework de for- 
mulaires de Symfony. 

Un point fondamental reste encore non traite au terme de ces quelques 
pages puisqu'en effet, aucun nouveau test n'a ete implemente pour les 
nouvelles fonctionnalites. Dans la mesure ou l'ecriture de tests est un 
enjeu crucial dans le developpement d'une application, ce sera le tout 
premier theme aborde au chapitre suivant. 
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Tester les formulaires 



MOTS-CLES 



Les formulaires sont des composants complexes a gerer 
dans une application web. Heureusement, le chapitre 
precedent a montre comment Symfony en facilite grandement 
la gestion a l'aide de son framework interne. 

Ce chapitre approfondit encore les connaissances liees 
aux formulaires en montrant les manieres de les tester 
fonctionnellement. 



► Tests fonctionnels 

► Securite XSS et CSRF 

► Creer des taches automatiques 



A ce stade, les utilisateurs ont la capacite de naviguer sur l'application a 
la recherche d'offres d'emploi, et d'en ajouter de nouvelles grace aux for- 
mulaires. Neanmoins, le formulaire de creation d'une nouvelle offre n'a 
pas encore ete teste pour s'assurer qu'il se comporte normalement. Ce 
chapitre couvre avant tout les notions de tests fonctionnels des formu- 
laires, et apporte quelques astuces supplementaires a propos du fra- 
mework de formulaire. 



Utiliser le framework de formulaires de 
maniere autonome 

Les composants de Symfony sont relativement decouples, ce qui signifie 
que la plupart d'entre eux sont exploitables de maniere autonome a 
l'exterieur du framework. Le framework de formulaire en fait partie 
puisqu'il ne dispose d'aucune dependance avec le reste de Symfony. Les 
classes de formulaire, les widgets ainsi que les validateurs sont ainsi reu- 
tilisables hors de l'environnement Symfony. Pour ce faire, il suffit de 
recuperer les repertoires lib/form/, lib/widget/ et lib/validator/ qui 
se trouvent dans le repertoire lib/vendor/symfony/ d'un projet. 

Parmi ces composants autonomes figure egalement le framework interne 
de routage, accessible dans le repertoire lib/routing/. Celui-ci permet 
de profiter pleinement et gratuitement des URLs bien formees. 



Figure 11-1 

Diagramme des composants 
independants de Symfony 



sfRequest sfRouting sfLogger 



;fl18N 



sfUser sfResponse 



sfYAML 




sfDatabase 



sfForm 



sfEventDispatcher 



sfStorage 



sfCache 



sfOutputEscaper 



sfValidator 



sfWidget 



sfCoreAutoload 



platform 



Apres cette breve introduction concernant la facilite d'utilisation du fra- 
mework de formulaire en dehors de l'environnement Symfony, il est 
temps d'entrer dans le vif du sujet. II s'agit de poursuivre le developpe- 
ment de l'application en s'interessant aux tests fonctionnels des formu- 
laires. Le neuvieme chapitre a presente globalement le but et le principe 
de fonctionnement des scenarios de tests fonctionnels. Jusqu'a mainte- 
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nant, ces derniers ont essentiellement servi a analyser le contenu HTML 
de la reponse grace notamment aux selecteurs CSS 3. Cet outil recele 
encore bien d'autres fonctionnalites puisqu'il offre egalement la capacite 
de tester n'importe quelle classe de formulaire. 

Ecrire des tests fonctionnels pour les 
classes de formulaire 

Les prochaines sections presentent les differents outils du framework de 
tests fonctionnels qui permettent de tester les formulaires. Ces derniers assu- 
rent au developpeur que le formulaire qu'il a ecrit se comporte convenable- 
ment en simulant le remplissage des champs ainsi que les telechargements 
de fichiers, et en diagnostiquant les erreurs generees par les validateurs. 

Tester renvoi du formulaire de creation d'offre 

La premiere etape du processus de test du formulaire de creation d'une 
nouvelle offre consiste a s'assurer que ce dernier est bien envoye avec 
toutes les valeurs obligatoires renseignees. Pour commencer, le code ci- 
dessous doit etre ajoute a la fin du fichier de tests fonctionnels 
jobActionsTest . php. 

Code a ajouter a la fin du fichier test/functional/frontend/jobActionsTest.php 

$browser->i nfo( ' 3 - Post a Dob page')-> 
infoC 3.1 - Submit a Job')-> 

get('/job/new')-> 

wi th ( ' request ' ) ->begi n () -> 

isParameter('module' , 'job')-> 

isParameter('action' , 'new')-> 
end() 

> 

Au neuvieme chapitre, la methode clickO de l'objet sfTestFunctional 
a ete utilisee pour simuler les clics sur des liens presents dans la page. 
Cette methode clickO fonctionne de la meme maniere pour soumettre 
un formulaire. En effet, elle accepte en second argument un tableau 
associatif des valeurs a envoyer pour chaque champ. Tel un veritable 
navigateur, l'objet Sbrowser fusionnera les valeurs par defaut du formu- 
laire avec celles qui ont ete soumises. 
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Renommer le nom des champs du formulaire 

Cependant, il faut connaitre a l'avance le nom des champs pour lesquels 
les valeurs doivent etre transmises. En ouvrant le code source HTML ou 
bien en utilisant la fonctionnalite Formulaires > Afficher les details du for- 
mulaire de la Firefox Web Developer Toolbar sur le formulaire en ques- 
tion, on remarque que le nom du champ company est en fait 
jobeet_job [company] . 

Lorsque PHP rencontre un champ de saisie avec un nom comme 
jobeet_job [company], il le convertit automatiquement en un tableau 
dont le nom est jobeet_job. Ce format de nommage des champs est un 
peu complexe et ne facilite pas forcement la tache. En ajoutant la ligne 
de code suivante a la fin de la methode configureO de la classe 
JobeetJobForm, les noms des champs suivront alors le format $job[%s] . 

| $this->widgetSchema->setNameFormat(' job[%s] ') ; 



Soumettre le formulaire a I'aide de la methode click() 

Apres ce changement, le nom du champ company devrait etre 
job [company] . II est maintenant l'heure de tester le clic sur le bouton Pre- 
view your job en fournissant un tableau de valeurs valides au formulaire, 
par le biais du second argument de la methode cl i ck(). 

Code de test de I'envoi du formulaire a ajouter au fichier test/functional/frontend/ 
jobActionsTestphp 

$browser->i nfo( ' 3 - Post a Job page')-> 
info(' 3.1 - Submit a Job')-> 

get('/job/new')-> 

wi th ( ' request ' ) ->begi n () -> 

i sParameter( 'module ' , 'job')-> 

i sParameter( ' action ' , 'new')-> 
end() 

click(' Preview your job', arrayC'job' => array( 
'company' => 'Sensio Labs', 

'url' => 'http://www.sensio.com/', 

'logo' => sfConfig: :get('sf upload dir') 

. '/jobs/sensio-labs.gif ' , 
'Developer' , 
'Atlanta, USA', 



=> 
=> 



' position ' 
'location' 

'description' => 'You will work with symfony to develop 
websites for our customers.', 

'how to apply' => 'Send me an email', 
'email' => 'for.a.job@example.com', 

'is_public' => false, 
)))-> 



200 



wi th ( ' request ' ) ->begi n () -> 

isParameter('module' , 'job')-> 

is Parameter ('acti on' , ' create ')-> 
endO ; 

Le code ci-dessus ne realise rien d'extraordinaire. En effet, il se charge 
simplement de transmettre les donnees du formulaire lorsque Ton clique 
sur le bouton Preview your job, puis de verifier que la page suivante cor- 
respond bien a Taction create du module job. La simulation des envois 
de fichiers est elle aussi prise en compte en fournissant le chemin absolu 
vers un fichier comme le montre le champ logo. 

Decouvrir le testeur sfTesterForm 

L'objet sfTesterForm est un testeur qui permet de verifier les donnees 
d'un formulaire comme le realise le testeur sfTesterResponse avec la 
reponse generee. 

Tester si le formulaire est errone 

Le testeur sfTesterForm fournit une methode bien pratique, 
hasErrorsO, pour tester si oui ou non le formulaire a genere des erreurs 
d'apres les donnees qui lui ont ete transmises. Lexemple de code ci-des- 
sous illustre son utilisation. 

with('form')->begin()-> 
hasErrors(fa1se)-> 

end(); 

Les methodes de l'objet sfTesterForm 

L'objet sfTesterForm dispose de bien d'autres methodes utiles pour recu- 
perer des informations sur l'etat du formulaire, comme les erreurs gene- 
rees. Le tableau suivant dresse une liste exhaustive des methodes de cet 
objet. 



Tableau 11-1 Liste des methodes de l'objet sfTesterForm 



Repertoire 


Description 


getFormO 


Retourne l'objet de formulaire courant 


hasErrorsO 


Retourne si oui ou non le formulaire a des erreurs 


hasGlobal Error() 


Retourne si oui ou non le formulaire a des erreurs globales 


isError(Sfield) 


Retourne si oui ou non le champ donne a des erreurs 


debugQ 


Affiche tout l'etat du formulaire en cours 



Deboguer un formulaire 

Lorsque un test echoue, le premier moyen de faciliter la decouverte du 
bug est d'utiliser la methode debug () sur le testeur sfTesterResponse 
afin d'obtenir la reponse generee par le serveur. Dans le cas d'un formu- 
laire, ce n'est veritablement pas pratique dans la mesure ou il faut 
plonger soi-meme dans le code HTML a la recherche des erreurs gene- 
rees pour chaque champ. 

Heureusement, le testeur sfTesterForm fournit la methode debugO qui 
permet d'imprimer en sortie l'etat complet du formulaire avec les erreurs 
levees. Le bout de code ci-dessous montre comment utiliser cette 
methode sur le testeur de formulaire. 

| with('form')->debugO 

Tester les redirections HTTP 

Dans Jobeet, lorsque le formulaire soumis par l'utilisateur est valide, ce 
dernier est automatiquement redirige vers la page de consultation de 
l'offre se trouvant a Taction show. De ce fait, il est necessaire de s' assurer 
que la redirection a bien eu lieu grace aux methodes isRedi rectedO et 
fol "lowRedi rect() comme le montre l'exemple de code ci-dessous. 

isRedirected()-> 
fol 1 owRedi rect () -> 

with(' request ')->begin()-> 

isParameter('modu1e' , 'job')-> 

isParameter('action' , 'show')-> 
end(); 

La methode isRedi rectedO indique si oui ou non ily a eu une redirec- 
tion tandis que la methode followRedi rect() suit cette derniere. Pour- 
quoi la classe du navigateur ne suit-elle pas automatiquement la 
redirection ? La raison est simple : c'est pour laisser au developpeur la 
liberte d'analyser l'etat des objets avant la redirection. 

Tester les objets generes par Doctrine 

Dans la plupart des cas, les formulaires sont destines a recuperer les 
informations de l'utilisateur afin de les stocker dans la base de donnees. 
Dans Symfony, c'est exactement ce que font les formulaires Doctrine 
puisqu'ils permettent de sauvegarder automatiquement les informations 
saisies dans une table. Cependant, comment s' assurer que les informa- 
tions ont bien ete enregistrees et que les valeurs de chaque champ corres- 
pondent a ce que Ton souhaite ? 



Activer le testeur sfTesterDoctrine 

Le framework interne de tests fonctionnels de Symfony introduit un 
nouveau testeur, l'objet sfTesterDoctrine, qui permet d'interroger une 
base de donnees. Contrairement aux testeurs vus jusqu'a present, le tes- 
teur Doctrine n'est pas reference par defaut dans l'objet 
sfTestFunctional. Pour l'activer, il suffit de le definir explicitement 
comme l'explique le code ci-dessous. 

| $browser->setTester(' doctrine' , 'sfTesterDoctrine'); 

Tester I'existence d'un objet Doctrine dans la base de donnees 

Dans le cadre de 1' application Jobeet, il est interessant de controler que 
l'offre d'emploi a bien ete creee et que la colonne i s_activated contient 
la valeur f al se dans la mesure ou l'utilisateur ne l'a pas encore publiee. 

Grace au testeur sfTesterDoctrine et a sa methode check(), il est tout a 
fait possible de verifier I'existence d'un ou de plusieurs objets dans la 
base de donnees qui correspondent a un critere donne. Le code suivant 
illustre l'utilisation du testeur Doctrine pour controler la creation de la 
nouvelle offre d'emploi. 

with('doctrine')->begin()-> 
check(' Jobeet Job' , array( 

'location' => 'Atlanta, USA', 
' i s_activated ' => false, 
'is_public' => false, 
))-> 
end() 

Le critere de recherche de la methode checkO peut s'exprimer de deux 
manieres differentes. II s'agit en effet de passer soit un tableau associatif 
comme dans l'exemple ci-dessus, soit une instance de la classe 
Doctri ne_Query dans le cas de requetes plus complexes. De plus, un troi- 
sieme argument facultatif peut lui etre transmis. Si ce dernier est boo- 
leen, il specifie s'il faut tester I'existence (true par defaut) ou bien 
l'absence (false) de l'objet dans la base de donnees. En revanche, si un 
nombre entier est passe en parametre, la methode checkO verifiera que 
le critere correspond au nombre de resultats. 

Tester les erreurs des champs du formulaire 

Tester un formulaire avec des valeurs valides ne suffit pas. II faut aussi 
s'assurer qu'il se comporte correctement lorsque des donnees invalides, 
voire potentiellement dangereuses, lui sont transmises. La premiere veri- 
fication consiste done a s'assurer que ces donnees ne sont pas considerees 



comme valides par les validateurs qu'elles traversent, et que ces derniers 
generent effectivement les messages d'erreur adequats. 



E 



La methode isError() pour le control e des champs 

La methode isErrorO du testeur sfTesterForm permet de tester si un 
champ du formulaire est errone en lui passant en parametres le nom du 
champ concerne et le code d'erreur du validateur (required, invalid, 
max_length, min_length...). 

Le code qui suit verifie que le formulaire leve trois erreurs pour les 
champs description, how_to_apply et email. Pour les deux premiers, il 
s'agit de s'assurer que leur valeur respective ne peut rester vide tandis que 
pour le champ emai 1 , on verifie que la valeur soumise ne correspond pas 
un format d'adresse e-mail valide. 

$browser-> 

info(' 3.2 - Submit a Job with invalid values')-> 
get('/job/new')-> 

click(' Preview your job', arrayCjob' => array( 

'company' => 'Sensio Labs', 

=> 'Developer' , 

=> 'Atlanta, USA' , 

=> ' not. an. email ' , 



' position ' 
' location ' 
'email ' 

)))-> 



wi th ( ' f orm ' ) ->begi n () -> 
hasErrors(3)-> 

isError('description' , 'required')-> 
isError('how to apply' , ' required ')-> 
isError('email ' , 'invalid')-> 

endQ 



En prenant une valeur entiere plutot qu'un booleen comme argument, la 
methode hasErrorsO verifie que le formulaire a genere exactement ce 
nombre d'erreurs. Dans le cas du test d'un formulaire avec des valeurs 
invalides, il est inutile de tester chaque champ. Seuls les plus sensibles ou 
les plus specifiques peuvent etre controles pour valider que le formulaire 
est bien mis en echec avec des donnees invalides. De plus, les compo- 
sants du framework interne de formulaire ont deja ete testes, ce qui 
donne l'assurance qu'ils se comportent correctement. 

Les veritables messages d'erreur peuvent egalement etre testes en utilisant 
la methode checkElementO du testeur sfTesterResponse. Cette tech- 
nique est particulierement recommandee lorsque les formulaires ont un 
layout personnalise. Dans 1' application Jobeet, le layout du formulaire est 
celui par defaut, c'est pourquoi les messages d'erreur ne sont pas testes. 
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Tester la barre d'administration d'une offre 

L'etape suivante consiste a tester les liens de la barre d'administration de la 
page de previsualisation d'une offre. Lorsqu'une offre nest pas encore 
activee, l'utilisateur a toujours la capacite de l'editer, de la publier ou bien 
de la supprimer en cliquant sur le lien correspondant. Afin de tester 
chacun de ces liens, il est necessaire de creer une nouvelle offre. Bien 
entendu, il est hors de question de copier/coller le code de creation d'une 
offre pour chacun des cas. Ce serait en effet laborieux, difficilement main- 
tenable et une veritable perte de temps. L'ideal est done de mutualiser ce 
code dans une nouvelle methode de la classe JobeetTestFunctional 
comme le montre le code suivant. 

Methode createJobO a ajouter au fichier lib/test/JobeetTestFunctional.class.php 

class JobeetTestFunctional extends sfTestFunctional 
{ 

public function createJob($val ues = arrayO) 
{ 

return $this-> 
get ( ' / j ob/new ' ) -> 
clickC Preview your job', 

arrayCjob' => array merge(array( 
'company' => 'Sensio Labs', 

'url' => 'http://www.sensio.com/', 

'position' => 'Developer', 
'location' => 'Atlanta, USA', 

'description' => 'You will work with symfony to develop 
websites for our customers.', 

'how to apply' => 'Send me an email', 

'email' => 'for.a.job@example.com', 

'is_public' => false, 
), $values)))-> 
followRedi rect() 

J 

} 

// ... 

} 

La nouvelle methode createJobO cree une nouvelle offre, suit la redi- 
rection et retourne le navigateur afin de ne pas casser l'interface fluide. 
Un tableau de valeurs peut egalement lui etre fourni en parametre. 
Celui-ci sera fusionne avec les valeurs par defaut afin de pouvoir rede- 
finir certaines d'entre elles facilement. 



Forcer la methode HTTP d'un lien 



Forcer ('utilisation de la methode HTTP PUT 

Au chapitre precedent, le lien Publish a ete configure pour fonctionner 
avec la methode HTTP PUT. Comme les navigateurs ne supportent pas 
les requetes PUT, le helper link_to() convertit le lien en un formulaire a 
l'aide d'un script JavaScript. 

Cependant, le navigateur de tests fonctionnels est incapable d'executer le 
moindre code JavaScript, c'est pourquoi la methode PUT doit etre forcee 
manuellement en la passant comme troisieme argument facultatif de la 
methode click(). 

De plus, le helper link_to() embarque un jeton CSRF puisque la pro- 
tection CSRF a ete activee lors du premier chapitre. L'option _with_csrf 
simule ce jeton. 

$browser->info(' 3.3 - On the preview page, you can publish the 
job')-> 

createJob(array('position' => 'F001'))-> 
c"Hck(' Publish' , arrayO , array (' method' => 'put', 
' with csrf => true))-> 

wi th ( ' doct ri ne ' ) ->begi n () -> 
check(' JobeetJob' , array( 
'position' => 'F001', 
'is_activated' => true, 

))-> 
end() 

II est alors possible de reproduire cet exemple pour tester le lien Delete 
qui necessite, quant a lui, le recours a la methode HTTP DELETE. 

Forcer ('utilisation de la methode HTTP DELETE 

Le fonctionnement du lien Delete est exactement le meme que celui du 
bouton Publish. II s'agit en effet de fournir cette fois-ci la valeur delete 
au parametre method, puis de s' assurer que l'objet a bien ete supprime de 
la base de donnees grace au testeur sfTesterDoctrine. 

$browser->info(' 3.4 - On the preview page, you can delete the 
job')-> 

create]ob(array('position' => 'F002'))-> 
click('Delete' , arrayO, arrayC method' => 'delete', 
'_with csrf' => true))-> 

with( ' doctri ne ' )->begin()-> 
check(' JobeetJob' , arrayC 



'position' => 'F002' , 
), false) -> 

endO 

J 

La section suivante explique en quoi l'ecriture de tests fonctionnels est 
un excellent moyen de decouvrir des bogues ou bien de detecter des 
fonctionnalites encore non implementees... 

Ecrire des tests fonctionnels afin de 
decouvrir des bogues 

Lorsqu'une offre est publiee, il devient impossible de l'editer par la suite. 
Bien que le lien Edit ait totalement disparu de la page de previsualisation, 
il est toujours possible d'avoir acces au formulaire d'edition de l'offre via 
FURL. Le seul moyen efficace de le verifier est bien sur d'ecrire quelques 
tests automatiques. 

Simuler I'autopublication d'une offre 

La premiere etape consiste a editer la methode createJobO en lui ajou- 
tant un nouvel argument facultatif permettant de forcer I'autopublica- 
tion de l'offre avant d'ecrire une nouvelle methode getJobByPositionO. 
Cette derniere se charge de recuperer et de retourner une offre d'emploi 
a partir de la valeur de la colonne posi ti on. 

Methodes createJobO et getJobByPositionO du fichier lib/test/ 
JobeetTestFunctional.class.php 

class JobeetTestFunctional extends sfTestFunctional 
{ 

public function createJob($val ues = arrayO , Spublish = false) 

{ 

$this-> 

get (' /job/new' )-> 

cl i ck( ' Previ ew your job', 

arrayCjob' => array_merge(array( 
'company' => 'Sensio Labs', 

'url' => 'http://www.sensio.com/', 

'position' => 'Developer', 
'location' => 'Atlanta, USA', 

'description' => 'You will work with symfony to develop 
websites for our customers.', 

' how_to_apply ' => 'Send me an email', 
'email' => 'for. a. job@example.com' , 

'is_public' => false, 



), $values)))-> 
followRedi rect() 



if ($pub"Hsh) 
{ 

$this-> 

click('Publish' , array(), arrayC method' => 'put', 

' with csrf => true))-> 
followRedirectO 

} 

return $this; 

} 

public function getJobByPosition($position) 
{ 

$q = Doctrine Query: :create() 
->from(' JobeetDob j') 
->where('j .position = ?', $position); 

return $q->fetchOne() ; 

} 

// ... 



Contrdler la redirection vers une page d'erreur 404 

Lorsqu'une offre est publiee, l'acces au formulaire d'edition ne doit plus 
etre possible et doit conduire vers une page d'erreur 404. Pour s'en 
assurer, il est necessaire d'ecrire quelques tests fonctionnels comme le 
presente le morceau de code ci-dessous. 

1 $browser->info(' 3.5 - When a job is published, it cannot be 
edited anymore')-> 

createJob(array( ' position ' => 'F003'), true)-> 

get(sprintf ( '/job/%s/edit' , $browser- 
>get JobByPosi tion ( ' F003 ' ) ->getToken ()))-> 

wi th ( ' response ' ) ->begi n () -> 
i sStatusCode (404) -> 

endQ 



Les trois lignes de code en exergue decrivent le scenario de test suivant : 

1 une nouvelle offre est creee et autopubliee ; 

2 le jeton de celle-ci est recupere pour construire FURL du formulaire 
d'edition et s'y rendre ; 



3 le testeur de reponse verifie que le statut HTTP de la reponse est bel 
et bien egal a 404 (page introuvable). 

En executant la suite de tests fonctionnels, le test du statut HTTP de la 
reponse echoue. Ce nest finalement pas si etonnant puisque Fimplemen- 
tation de cette fonctionnalite a ete oubliee lors du chapitre precedent. 

En somme, les tests automatiques sont un excellent moyen de faire 
apparaitre des effets de bord, des bogues ou bien encore des fonctionna- 
lites importantes non implementees. Lecriture de tests demande aux 
developpeurs de penser a tous les cas de figure possibles, ce qui nest pas 
systematique lorsqu'ils developpent chaque fonctionnalite. 

Empecher 1'acces au formulaire d'edition lorsque I'offre 
est publiee 

Fixer le bogue decouvert dans la section precedente est a present tres 
simple dans la mesure ou le test fonctionnel en donne la solution : redi- 
riger vers une page d'erreur 404 lorsque l'offre demandee est deja 
publiee. Pour ce faire, il suffit d'avoir recours a la methode 
forward404If () dans Faction executeEditO du module job. 

Methode executeEditO du fichier apps/frontend/modules/job/actions/ 
actions.class.php 

public function executeEdi t(sfWebRequest Srequest) 
{ 

$job = $this->getRoute()->get0bjectO ; 
$this->forward404If($job->getIsActivated()) ; 

$this->form = new ]obeetJobForm($job) ; 

} 

Le correctif est trivial mais ne garantit pas que tout fonctionne toujours 
correctement. Un moyen simple de s'en assurer est d'ouvrir le navigateur 
et de tester toutes les combinaisons possibles pour acceder au formulaire 
d'edition. C'est une methode somme toute fastidieuse... 

La meilleure facon de proceder consiste bien evidemment a relancer 
toute la suite de tests fonctionnels car ces derniers permettent d'une part 
de verifier que le correctif repond cette fois-ci au test ecrit, et d'autre 
part qu'aucune regression fonctionnelle n'a aussi ete entrainee suite a la 
modification de Faction executeEditO. 



Bonne pratique 
Eviter les taches fastidieuses 

Les taches fastidieuses sont nombreuses dans le 
developpement d'une application web. Nean- 
moins, il faut se rappeler que si une tache est fasti- 
dieuse et rebarbative, il existe probablement un 
outil permettant de les realiser a la place du deve- 
loppeur. C'est un etat d'esprit a garder constam- 
ment, surtout lors de I'utilisation d'outils aussi 
complets que Symfony. 
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Tester la prolongation (Tune offre 



Dans Jobeet, lorsqu'une offre d'emploi expire dans les cinq prochains 
jours, ou lorsqu'elle est deja arrivee a expiration, l'utilisateur a la possibi- 
lity de prolonger sa duree de vie de trente jours supplementaires a 
compter de la date courante. 

Comprendre le probleme des offres expirees a reactiver 

Tester cette contrainte dans un navigateur n'est pas si facile dans la mesure 
ou la date d'expiration est automatiquement definie a trente jours lors de la 
creation de 1' offre. Ainsi, lorsque Ton accede a la page de consultation de 
l'offre, le lien pour la prolonger n'est pas present. Bien sur, il est possible de 
« pirater » la date d'expiration dans la base de donnees, ou bien de person- 
naliser le template pour qu'il affiche toujours le lien, mais c'est a la fois fas- 
tidieux et annonciateur d'erreur. On l'aura devine, ecrire des tests est une 
fois de plus une aide particulierement appreciee. 

Une route dediee pour prolonger la duree d'une offre 

Pour permettre a l'auteur de prolonger son annonce sur le site, la pre- 
miere etape consiste comme d'habitude a penser puis definir la route 
correspondante. C'est exactement ce que realise le code ci-dessous en 
ajoutant une nouvelle route a la collection de routes Doctrine de l'objet. 

Ajout de la nouvelle route extend a la collection de routes d'une offre dans le fichier 
apps/frontend/config/routing.yml 

job: 

class: sfDoctrineRouteCollection 
options : 

model : JobeetJob 

column: token 

object_actions : { publish: PUT, extend: PUT } 
requi rements : 
token : \w+ 

Apres cela, il suffit de mettre a jour le template partieLadmi n . php afin de 
lui specifier la methode PUT pour le lien Extend. 



Extrait du fichier apps/frontend/modules/job/templates/_admin.php 

<?php if ($job->expi resSoonO) : ?> 

- <?php echo "link to(' Extend ' , 'job extend' , $job, 

arrayC method' => 'put')) ?> for another <?php echo 

sfConfig: : get( ' app_acti ve_days ' ) ?> days 

<?php endif; ?> 

Implementer la methode executeExtendO aux actions 
du module job 

Maintenant que la route est proprement definie, le prochain objectif est 
d'implementer la nouvelle action executeExtendO qui a pour role de 
prolonger la duree de vie d'une offre, a condition que celle-ci arrive 
bientot a expiration. 

Methode executeExtendO a ajouter au fichier apps/frontend/modules/job/actions/ 
actions.class.php 

public function executeExtend(sfWebRequest Srequest) 
{ 

$request->checkCSRFProtection() ; 

$job = $this->getRoute()->get0bjectO ; 
$thi s->forward404Unless($job->extend()) ; 

$this->getUser()->setFlash('notice' , sprintf ('Your job 
validity has been extend until %s . ' , date('m/d/Y' , 
strtotime($job->getExpi resAt())))) ; 

$this->redi rect($thi s->generateUrl ( ' job_show_user ' , $job)) ; 

} 

Le code de cette nouvelle action est tres simple a comprendre. 

1 La methode checkCSRFProtectionO controle la validite du jeton 
transmis suite au clic sur le lien Extend. 

2 Puis l'offre d'emploi est retrouvee a partir de sa route et de son propre 
jeton. La methode extend () de l'objet JobeetJob prolonge la duree 
de vie de l'offre pour une nouvelle periode de 30 jours a condition 
que celle-ci arrive a expiration prochainement. Dans le cas contraire, 
l'utilisateur est automatiquement redirige vers une page d'erreur 404. 

3 Enfin, si tout s'est bien deroule, l'utilisateur est automatiquement 
redirige vers son annonce en profitant d'un message lui informant de 
la nouvelle date d'expiration de son offre. 



Implementer la methode extendO dans JobeetJob 

A present, il ne reste plus qua implementer la methode extend () a la 
classe JobeetJob avant de s' assurer que cette nouvelle fonctionnalite est 
entierement operationnelle grace a quelques scenarios de tests fonction- 
nels. Le code suivant presente le detail de la methode extend (). 

Methode extendO a ajouter au fichier lib/model/doctrine/JobeetJob.class.php 

class JobeetJob extends BaseJobeetJob 
{ 

public function extendO 
{ 

if (!$this->expiresSoon()) 
{ 

return false; 

} 

$this->setExpiresAt(date( , Y-m-d' , time() + 86400 * 

sfConfig: :get('app active days'))) ; 

$this->save() ; 
return true; 

} 

// ... 

} 

La encore, le code de la methode est suffisamment clair, intuitif et expli- 
cite pour ne pas etre commente davantage. Cette methode retourne 
immediatement false si l'offre n'est pas sur le point d'expirer. Dans le 
cas contraire, la nouvelle date d'expiration est recalculee et l'objet est 
serialise en base de donnees avant de retourner true. 

Tester la prolongation de la duree de vie d'une off re 

La derniere etape consiste a verifier avec quelques scenarios de test que 
la nouvelle fonctionnalite a bien ete implementee et quelle ne provoque 
pas d'effet de bord ou de regression pour les autres fonctionnalites deja 
implementees. 

Une offre ne peut etre prolongee si elle n'expire pas bientot 

Le premier test a effectuer doit verifier que l'utilisateur ne peut pro- 
longer la duree de vie de son annonce si cette derniere n'est pas sur le 
point d'expirer. Le test controle que l'utilisateur est redirige automati- 
quement vers une page d'erreur 404 comme le montre le bout de code 
ci-dessous. 



$browser->i nfo( ' 3.6 - A job validity cannot be extended before 
the job expires soon')-> 

createJob(array('position' => 'F004'), true)-> 
call (sprintf ('/job/%s/extend' , 

$browser->get JobByPosi t i on ( ' F004 ' ) ->getToken () ) , 
'put', arrayC with csrf' => true))-> 
with(' response ')->begin()-> 

isStatusCode(404)-> 
endO 

> 

On note ici l'utilisation de la methode cal 1 () a la place de get() pour exe- 
cuter la prolongation de la duree de vie de l'offre. cal 1 () sert effectivement a 
appeler des URLs dont la methode HTTP est differente de GET ou POST. 

Une offre peut etre prolongee uniquement si elle expire bientot 

Le second test consiste a verifier cette fois-ci qu'une offre prete a expirer 
peut etre prolongee. C'est le scenario que teste le code suivant. 

$browser->i nfo( ' 3.7 - A job validity can be extended when the 
job expi res soon')-> 

createJob(array('position' => 'F005'), true) 



$job = $browser->get]obByPosition('F005') ; 
$job->setExpi resAt(date('Y-m-d')) ; 
$job->save() ; 

$browser-> 

call (sprintf ('/job/%s/extend' , $job->getToken()) , 'put', 
arrayC with csrf => true))-> 

with(' response ')->isRedi rectedQ 



$job->ref resh() ; 
$browser->test()->is( 

date('y/m/d' , strtotime($job->getExpi resAt())) , 

date('y/m/d' , time() + 86400 * 
s f Con f i g : : get ( ' app ac t i ve day s ' ) ) 

); 

Qyelques nouvelles explications s'imposent ici. De la meme maniere qu'avec 
le scenario precedent, la methode cal 1 () appelle l'URL avec la methode 
PUT et un jeton. On constate que l'utilisateur est bien redirige mais la redi- 
rection n'est pas suivie afin d'effectuer quelques tests supplementaires. 

Tout d'abord, l'offre d'emploi est rafraichie ($job->ref resh()) dans le 
but de prendre en compte les modifications. Ensuite, le timestamp sau- 
vegarde en base de donnees est compare avec celui de la date courante 
plus trente jours a l'aide de l'objet 1 i me_test du navigateur. 



Securiser les formulaires 



Le framework interne de formulaire de Symfony integre nativement des 
points de securite a differents endroits. La creation de jeton unique pour 
chaque formulaire, l'echappement automatique des donnees contre les 
failles de type « Cross Site Scripting » (XSS) ou bien encore l'injection 
de transactions SQL lors de la sauvegarde d'un objet en base de donnees 
sont d'autant de points sensibles a proteger. Heureusement, Symfony 
soulage le developpeur de cette tache. 

Serialisation d'un formulaire Doctrine 

Les formulaires Doctrine sont tres simples a utiliser dans la mesure ou ils 
automatisent une grande partie du travail du developpeur. Par exemple, 
serialiser un formulaire Doctrine en base de donnees consiste en un 
simple appel a la methode save() du formulaire : $form->save(). 

Mais concretement, que se passe-il dans cette methode ? La methode 
save() deroule en fait les etapes suivantes une a une : 

1 demarrage d'une transaction SQL car les formulaires imbriques Doc- 
trine sont tous sauvegardes d'un seul coup ; 

2 traitement des valeurs soumises en appelant les methodes 
updateCOLUMNColumnO si elles existent ; 

3 appel de la methode f romArrayO de l'objet Doctrine pour mettre a 
jour les valeurs des colonnes ; 

4 sauvegarde de l'objet en base de donnees ; 

5 validation de la transaction. 

Lutilisation de la methode f romArrayO peut potentiellement engendrer 
une faille de securite non negligeable pour le systeme d'information si 
elle est mal utilisee. Heureusement, le framework interne de formulaire 
de Symfony realise les traitements adequats pour s'en premunir. La sec- 
tion suivante explique en detail comment cette securite est implementee. 

Securite native du framework de formulaire 

La methode fromArrayO prend un tableau de valeurs en parametre et 
met a jour les valeurs des colonnes correspondantes. En quoi est-ce que 
cela represente un eventuel probleme de securite ? Que se passe-t-il si 
quelqu'un essaie de soumettre sans l'autorisation necessaire une valeur a 
une colonne ? Par exemple, est-il possible de forcer la valeur de la 
colonne token directement dans le formulaire ? 



Le meilleur moyen de s'en assurer est d'ecrire un nouveau test qui simule 
la soumission d'un formulaire de creation d'offre d'emploi dans lequel se 
trouve un champ supplemental token. 

Code a ajouter au fichier test/functional/frontend/jobActionsTest.php 

$browser-> 

get('/job/new')-> 

click(' Preview your job', arrayCjob' => array( 
' token ' => ' fake token ' , 

)))-> 

with('form')->beginO-> 
hasErrors(7)-> 

hasCl obal Error ( ' ext ra fi el ds ' ) -> 

end() 

Lorsque le formulaire est soumis, une erreur globale de type 
extras-fields est levee. C'est en effet parce que par defaut, les formu- 
laires n'acceptent pas la presence de champs supplementaires parmi les 
valeurs transmises. C'est aussi pour cette raison que tous les champs de 
formulaire doivent posseder un validateur associe. 

Toutefois cette mesure de securite peut etre outrepassee en fixant 
l'option allow_extra_fields a true. 

class MyForm extends sfForm 
{ 

public function configure() 
{ 

// ... 

$thi s->val i datorSchema->setOpt i on ( ' all ow ext ra f i el ds ' , 
true) ; 

} 

} 

Le test devrait a present passer bien que la valeur du champ token a ete 
filtree. Ainsi, il n'est toujours pas possible de franchir cette mesure de 
securite. Pour rendre veritablement possible ce cas de figure, il suffit de 
fixer la valeur de l'option fi 1 ter_extra_f i el ds a fal se. 

$thi s->val i datorSchema->setOpti on ( ' f i 1 ter_ext ra_f i elds' , 
false) ; 

Les tests ecrits dans cette section ne sont qua but demonstratif. lis peu- 
vent etre retires du projet Jobeet dans la mesure oil il n'est pas necessaire 
de valider des fonctionnalites de Symfony deja testees. 



ASTUCE Modifier un formulaire avec la 
Firefox Web Developer Toolbar 

Des outils comme la celebre Firefox Web Developer 
Toolbar permettent de modifier les valeurs des 
champs d'un formulaire mais aussi d'en ajouter de 
nouveau simplement depuis le navigateur. 
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Se proteger contre les attaques CSRF et XSS 

Au cours du premier chapitre, l'application f rontend a ete creee a partir 
de la ligne de commande suivante. 

$ php symfony generate :app --escaping-strategy=on --csrf- 
secret="Unique$ecret" frontend 

L'option --escapi ng-strategy active la protection contre les failles de 
securite XSS, ce qui signifie que toutes les variables utilisees dans les 
templates sont echappees par defaut. Lors de la creation d'une nouvelle 
offre d'emploi, si la description de cette derniere contient des balises 
HTML, alors la description de l'annonce dans la page de consultation 
de detail sera rendue par Symfony comme etant du texte plein et non 
interpreted comme du code HTML par le navigateur. 

L'option --csrf-secret active la protection contre les failles de securite 
CSRF (prononcer « Sea Surf »). Lorsque cette option est activee, tous 
les formulaires integrent un champ cache _csrf_token. 

La strategic d'echappement et la cle secrete contre les CSRF peuvent 
etre modifiees a n'importe quel moment en editant manuellement le 
fichier de configuration apps/frontend/config/settings.yml. De la 
meme maniere que le fichier databases. yml, les parametres de configu- 
ration sont configurables par environnement. 

all : 

. setti ngs : 

# Form security secret (CSRF protection) 
csrf secret: Unique$ecret 

# Output escaping settings 
escaping strategy: on 

escapi ng method : ESC SPECIALCHARS 

Avant de terminer ce chapitre, il est interessant de passer quelques 
minutes sur la creation de taches automatiques propres au projet. Dans 
le cadre de Jobeet, il s'agit d'ecrire une tache qui se charge de supprimer 
de la base de donnees toutes les offres d'emploi expirees depuis un cer- 
tain nombre de jours. 



Les taches automatiques de maintenance 

Symfony est un framework web, mais il n'en est pas moins livre avec un 
outil fonctionnant en ligne de commande. Ce dernier a deja ete utilise a 
plusieurs reprises pour creer l'architecture par defaut du projet et de l'appli- 



cation, ou bien encore pour generer quelques fichiers du modele. Ajouter 
une nouvelle tache est simplissime dans la mesure ou les outils utilises par la 
ligne de commande Symfony sont deja integres dans le framework. 

Creer la nouvelle tache de maintenance jobeetdeanup 

Lorsque l'utilisateur cree une nouvelle offre d'emploi, il doit imperative- 
ment l'activer pour la mettre en ligne. A defaut et avec le temps, la base de 
donnees continuera de grossir avec des annonces hors ligne. II devient 
done utile de creer une tache automatique qui se charge de supprimer 
toutes les offres non publiees de la base de donnees. Pour eviter d'avoir a la 
lancer regulierement a la main, cette tache doit etre executee periodique- 
ment sous forme d'une tache automatique planifiee (cron job). 

Nouvelle tache automatique de maintenance a creer dans le fichier lib/task/ 
JobeetCleanupTask.class.php 

class JobeetCleanupTask extends sfBaseTask 
{ 

protected function configureO 
{ 

$thi s->addOptions (array ( 

new sf CommandOpti on ( ' appl i cati on ' , null, 

sf CommandOpti on : : PARAMETER_REQUIRED , 
'The application', 'frontend'), 
new sf CommandOpti on ( ' env' , null, 

sf CommandOpti on : : PARAMETER_REQUIRED , 
'The envi ronement ' , 'prod'), 
new sfCommandOpti on ('days' , null, 

sf CommandOpti on : : PARAMETER_REQUIRED , " , 90) , 

)); 

$this->namespace = 'jobeet'; 
$this->name = 'cleanup'; 

$this->briefDescription = 'Cleanup Jobeet database'; 

$this->detailedDescription = «<E0F 
The [jobeet: cleanup | INFO] task cleans up the Jobeet database: 

[./symfony jobeet : cl eanup --env=prod --days=90 | INFO] 
EOF; 
} 

protected function execute($arguments = arrayO, 

Soptions = arrayO) 

{ 

$databaseManager = new sfDatabaseManager($this 

^configuration) ; 

$nb = Doctrine: :getTab1e(' Jobeet Job') 

->cleanup($options['days']) ; 



$this->"logSection(' doctrine' , 

sprintfC Removed %d stale jobs', $nb)); 

} 

} 

La configuration de la tache est realisee dans la methode configure(). 
Chaque nouvelle tache doit avoir un nom unique (namespace: name), et 
peut prendre des arguments et des options en guise de parametres. Pour 
en savoir plus sur les taches internes de Symfony, il suffit de regarder 
dans le repertoire 1 i b/task du framework Symfony pour analyser le code 
source de quelques unes d'entre elles. 

Comme la nouvelle classe vient tout juste d'etre creee, il faut bien evidem- 
ment reactualiser le cache de Symfony pour quelle soit prise en compte. 

j $ php symfony cc 

La tache jobeet: cleanup definit deux options: --env et --days avec 
pour chacune une valeur par defaut. Tout le manuel d'utilisation de la 
tache est consultable en executant la commande suivante. 

| $ php symfony help jobeet:cleanup 

Enfin, pour l'executer, il suffit de l'appeler en ligne de commande tout sim- 
plement grace a l'executable Symfony comme le montre le code suivant. 

| $ php symfony jobeet : cl eanup --days=10 --env=dev 

Implementer la methode cleanupO de la classe 
JobeetJobTable 

La tache n'est pas totalement fonctionnelle puisqu'il lui manque l'imple- 
mentation de la methode cleanupO dans la classe JobeetJobTable. C'est 
effectivement celle-ci qui s'occupe veritablement de construire et 
d'appeler la bonne requete SQL qui nettoie la base de donnees, comme 
le montre le code ci-dessous. 

Methode cleanupO a ajouter au fichier lib/model/doctrine/JobeetJobTable.class.php 

public function cleanup(Sdays) 
{ 

$q = $this->createQuery('a') 
->delete() 

->andWhere('a.is_activated = ?', 0) 
->andWhere('a.created_at < ?', 

dateC'Y-m-d' , time() - 86400 * $days)); 

return $q->execute() ; 

} 



Les taches de Symfony se comportent parfaitement avec leur environne- 
ment puisqu'elles retournent une valeur en cas de succes. De ce fait, la 
valeur de retour par defaut peut etre forcee en retournant explicitement 
un entier a la fin de la tache. 



En resume... 

Tester le code est au cceur de la philosophic Symfony et de ses outils. 
Dans ce chapitre, nous avons vu une fois de plus comment nous servir 
efficacement des outils de Symfony pour rendre le processus de develop- 
pement plus facile, plus rapide et surtout plus sur. 

Le framework Symfony fournit bien plus que ces quelques widgets et 
validateurs. II offre en realite une maniere souple de tester les formu- 
laires pour s' assurer qu'ils sont securises par defaut. 

Ce nouveau tour d'horizon des fonctionnalites de Symfony s'acheve ici 
pour ce chapitre. Dans le chapitre suivant, il sera question de la creation 
de l'interface d'administration dans l'application backend. Creer un back 
office d'administration est un passage oblige pour la plupart des projets 
web, et bien sur Jobeet ne deroge pas a cette regie. La question qui se 
pose alors est : « Comment creer une telle interface d'administration 
complete et fonctionnelle en seulement quelques minutes ? ». C'est en 
fait extremement facile avec l'aide du celebre generateur d'administra- 
tion de Symfony. . . 



chapitre 




Jobeet 



lobs Categories 



JOB MANAGEMENT 


□ Company Position Location Url Activated? Email Actions 


Category id 


D programming - Sensio Labs (job@example.com) is H Extend 
looking for a Web Developer (Paris, France) ^ Edit 

■ ' Delete 


Company 

O is empty 


B Design - Extreme Sensio [job@example.com) is looking Extend 
for a Web Designer (Paris, France) " EdlT 

Delete 


Position 

□ is empty 


O <f programming - Sensio Labssss (Job@example.com) is Extend 
looking for a Web Developer (Paris, France) * Edlt 

■ Delete 


Description 

□ is empty 


- Programming - Company 100 [job@example.eom) is Extend 
looking for a Web Developer (Paris, France) ^ Edit 

X Delete 


Activated? 'yes or no FT) 

Whether rhe user has activated the job 


Public? [ yes or no *H 


Q programming - Company 101 (Job@example.com) is Extend 
looking for a Web Developer (Paris, France) * Edit 

Delete 


Email 

□ is empty 


□ Programming - Company 102 (Job@example.com) is Extend 
looking for a Web Developer (Paris, France) * Ed " 

X Delete 




D - : Programming - Company 103 (Job@example.com) is Extend 
looking for a Web Developer (Paris, France) * EdiI 

W rtfllora 


Reset ( Filter > 





Le generateur d'interface 
d'administration 



MOTS-CLES 



Concevoir une interface d'administration pour une application 
web grand public est une tache courante et fastidieuse 
a realiser. En effet, la plupart des ecrans d'un backoffice 
suivent le meme schema : des listes ordonnees et paginees, 
des formulaires de creation et d'edition du contenu, 
des outils de recherche. . . 

Le framework Symfony dispose d'un outil capable 
d'automatiser entierement la generation de telles interfaces 
mais aussi d'en simplifier la configuration sans avoir 
(ou presque) a ecrire de code PHP. 



► Generateur d'administration 

► Fichier de configuration 
generator.yml 

► Actions CRUD 



L'application developpee tout au long de cet ouvrage est destinee avant 
tout a etre alimentee par de simples utilisateurs. Tous les usagers sont 
libres de creer et de publier de nouvelles offres sur le site Internet. Nean- 
moins, cette grande liberte qui leur est offerte doit aussi etre encadree 
pour eviter toute derive ou publication de contenus non conformes aux 
regies du site. C'est la l'un des multiples avantages de l'interface d'admi- 
nistration d'une application Symfony. 

Avec les nouvelles fonctionnalites implementees au chapitre precedent, 
l'application frontend grand public est desormais entierement utilisable 
par les utilisateurs a la recherche d'emploi ou bien par ceux qui propo- 
sent de nouvelles offres. II est done temps de s'interesser au developpe- 
ment d'une interface d'administration, developpement qui sera 
rapidement realise grace au generateur de backoffice (« admin 
generator ») de Symfony. 



Creation de l'application « backend » 



ASTUCE Utiliser des caracteres speciaux 
pour le jeton CSRF ? 

Si la valeur de I'option --csrf-secret con- 
tient des caracteres speciaux comme un signe $ 
(dollar) par exemple, ces derniers doivent etre 
explicitement echappes a I'aide d'un antislash 
dans la console de lignes de commande. 
$ php symfony generate :app 
--csrf-secret=Unique\$ecret backend 



Generer le squelette de l'application 

La toute premiere etape de ce nouveau chapitre consacre a la generation 
du backoffice consiste a creer une nouvelle application « backend ». 
Cette operation a deja ete presentee au premier chapitre de cet ouvrage 
avec 1'utilisation de la tache gene rate :app. 

$ php symfony generate :app --escapi ng-strategy=on 
--csrf-secret=UniqueSecretl backend 

Bien que l'application se destine uniquement aux administrateurs de 
Jobeet, toutes les mesures de securite natives ont ete activees. 

L'application backend est maintenant disponible a l'adresse http:// 
jobeet. localhost/backend. php/ pour l'environnement de production, et a 
http://jobeet.localhost/backend_dev.php/ pour celui de developpement. 



Recharger les jeux de donnees initiales 

Le chargement des donnees initiales en base de donnees a partir de la 
tache doctrine: data- load ne fonctionne plus du tout a present. C'est en 
fait parce que la methode JobeetJob: : save() a besoin d'acceder au 
fichier de configuration app.yml de l'application frontend. Comme le 
projet est maintenant compose de deux applications, Symfony utilise le 
premier qu'il trouve ; en l'occurrence celui de l'application backend. 
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Lideal est done de partager le contenu du fichier de configuration de 
l'application frontend avec celui de 1'application backoffice. Depuis 
l'arrivee de Symfony 1.2, cette operation est desormais rendue possible. 

Le huitieme chapitre a montre que les parametres du projet pouvaient 
etre configures a differents niveaux. En deplacant le fichier apps/ 
frontend/config/app.yml dans le repertoire global config/, les parame- 
tres de configuration seront alors partages par l'ensemble des applica- 
tions du projet. Ce changement resout le probleme, et se revele 
important pour la suite du chapitre dans la mesure oil les classes de 
modele et les variables de configuration seront sollicitees directement 
dans le generateur de backoffice. 



ASTUCE Charger des donnees initiales a 
partir d'une configuration specif ique 

La tache doctri ne: data-load accepte ega- 
lement un parametre facultatif 
apppli cation qui permet de charger les don- 
nees initiales de test en utilisant la configuration 
propre a l'application mentionnee. 
$ php symfony doctrine: data-load -- 
appl i cati on=f rontend 



Generer les modules d 'administration 

La nouvelle etape reside dans la creation des modules de gestion des 
categories et des offres. Bien stir, il est hors de question de demarrer avec 
deux modules vides, puis de developper les differentes actions CRUD a 
la main pour ces deux derniers. Le generateur de backoffice de Symfony 
automatise toutes ces taches afin de fournir des modules entierement 
fonctionnels et personnalisables. 



Generer les modules category et job 

Pour l'application frontend, c'estla tache doctri ne:generate-module qui 
a ete utilisee pour generer un module basique CRUD reposant sur une 
classe de modele. En ce qui concerne l'application backoffice, e'est la 
commande doctrine: gene rate-admin qui se charge de batir une inter- 
face complete d'administration pour une classe de modele donnee. 

$ php symfony doctri ne : generate-admi n backend JobeetJob --module=job 

$ php symfony doctri ne : generate-admi n backend JobeetCategory --module=category 



Ces deux commandes creent les modules job et category pour les classes 
de modele respectives JobeetJob et JobeetCategory. Loption facultative 
--modul e surcharge le nom du module genere par defaut par la tache, qui 
aurait ete jobeet_job pour la classe JobeetJob. De plus, la tache cree 
aussi une collection de routes Doctrine dediee pour chaque module. 

Sans surprise, la classe de la route utilisee par le generateur d'administra- 
tion est sfDoctrineRouteCoUection, puisqu'une interface d'administra- 
tion a pour but de gerer tout le cycle de vie des objets du modele. La 
definition de la route declare egalement quelques options vues prece- 
demment dans cet ouvrage : 

• prefix_path : determine le prefixe du chemin pour la route generee. 
Par exemple, la page d'edition sera accessible a FURL /job/l/edit ; 



Bonne pratique Lire le manuel des taches 
automatiques de Symfony 

Le framework Symfony, et plus particulierement 
les taches automatiques, regorgent d'options et 
de parametres, permettant de coller au plus pres 
des besoins du developpeur. Une bonne pra- 
tique a adopter est done de lire la documenta- 
tion de la tache concernee, et ce, avant toute 
utilisation. 

$ php symfony help 

doctri ne : generate-admi n 
Le manuel presente tous les arguments et 
options possibles pour chaque tache ainsi que 
quelques exemples pratiques simples. 
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• col umn : definit la colonne de la table a utiliser dans l'URL pour les 
liens qui referencent un objet ; 

• with_wildcard_routes : puisque 1' administration aura des operations 
supplementaires en plus des actions CRUD classiques, cette option 
permet de declarer plus d'actions d'objet et de collection sans avoir a 
editer la route. 

Personnaliser I'interface utilisateur 

et I'ergonomie des modules du backoffice 

Decouvrir les fonctions des modules d'administration 

Lexecution des deux lignes de commande precedentes a suffi a generer 
deux modules d'administration complets et parfaitement operationnels. 
lis sont respectivement disponibles aux URLs suivantes. 

• http://jobeet.localhost/backend_dev.php/job 

• http://jobeet.localhost/backend_dev.php/category 

Les modules d'administration disposent de tout un tas de fonctionna- 
lites supplementaires en comparaison des modules auto generes tradi- 
tionnels etudies lors des chapitres precedents. Sans avoir ecrit la moindre 
ligne de code PHP, chaque module integre ces quelques fonctionnalites 
ultimes : 

• la liste des objets est paginee ; 

• la liste est ordonnable grace aux en-tetes du tableau ; 

• la liste peut etre filtree par le biais du formulaire de recherche sur la 
droite de l'ecran ; 

• les objets peuvent etre crees, edites ou supprimes ; 

• les objets selectionnes peuvent etre supprimes par lot ; 

• la validation des formulaires est active ; 

• les messages flash donnent immediatement des feedbacks a 
l'utilisateur ; 

• et bien plus encore ! 

Le generateur de backoffice fournit toutes les fonctionnalites necessaires 
pour creer soi-meme une interface de pilotage et ce, tres simplement. 



Ameliorer le layout du backoffice 

Dans le but d'ameliorer l'experience utilisateur, il est necessaire de per- 
sonnaliser davantage l'interface graphique du backend. Les deux 
modules sont pour 1'instant accessibles individuellement par leur URL, 
ce qui n'est pas specialement pratique. . . Le code suivant contient le con- 
tenu du fichier layout. php de i'application backend. Ce dernier imple- 
mente entre autres un menu de liens afin de faciliter la navigation entre 
les differents modules. 

Contenu du layout dans le fichier apps/backend/templates/layoutphp 

<!D0CTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" 
"http : //www . w3 . org/TR/xhtml 1/DTD/xhtml 1-t ransi ti onal . dtd"> 

<html xmlns="http://www. w3.org/1999/xhtml" xml : 1 ang="en" 

lang="en"> 
<head> 

<title>Jobeet Admin Interface</title> 

<link rel="shortcut icon" href="/favicon.ico" /> 

<?php use stylesheet ('admin. ess') ?> 

<?php include javascripts () ?> 

<?php include stylesheets () ?> 
</head> 
<body> 

<div i d="contai ner"> 
<div id="header"> 
<hl> 

<a href="<?php echo url_for(' ©homepage') ?>"> 

<img src="/images/jobeet.gif" alt="lobeet lob Board" /> 
</a> 
</hl> 
</di v> 

<div id="menu"> 
<ul> 
<li> 

<?php echo link to(' Jobs' , '@jobeet job') ?> 
</li> 
<li> 

<?php echo link to('Categories' , '©jobeet category') ?> 
</li> 
</ul> 
</div> 

<div id="content"> 

<?php echo $sf_content ?> 
</di v> 

<div id="footer"> 

<img src="/images/jobeet-mi ni . png" /> 

powered by <a href="http://www. symfony-project.org/"> 

<img src="/images/symfony.gif" alt="symfony framework" /> 

</a> 
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</di v> 
</di v> 
</body> 
</html> 

Ce layout utilise une feuille de style admin. ess qui doit etre obligatoire- 
ment presente dans le repertoire web/css installe au chapitre 4 avec les 
autres fichiers CSS. 



Jobeet 



lobs Categories 



CATEGORY LIST 



Figure 12-1 

Ecran d'accueil du 
module de gestion des 
categories 



□ Id Name 


Slug 


Actions 




□ 13 Design 


design 


Edit 


H Delete 


□ 14 Programming 


programming 


Edit 


X Delete 


□ 15 Manager 


manager 


' Edit 


X Delete 


Q 16 Administrator 


administrator 


✓ Edit 


X Delete 


4 results 



Choose an action ~i] ^go^ New 



Name 



□ is empty 



Slug 



□ is empty 
Jobeet category affiliate list [ i+j 



Reset ( Filter 1 



Dans la foulee, l'URL de la page d'accueil du backend peut etre rem- 
placee par la liste des offres d'emploi du module job. Pour ce faire, il 
suffit de modifier la route homepage du fichier de configuration 
routing. yml de l'application. 

Extrait du fichier apps/backend/config/routing.yml 

homepage : 
iirl : / 

param: { module: job, action: index } 

L'etape suivante consiste a penetrer davantage dans les entrailles du code 
genere pour chaque module d'administration. II y a en effet beaucoup a 
apprendre sur le fonctionnement du framework Symfony, a commencer 
par le cache. 
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Comprendre le cache de Symfony ] 

II est temps de decouvrir comment fonctionnent les modules generes, ou 2! 

du moins d'etudier leur code source pour comprendre ce qua genere la « 

tache automatique pour chacun d'eux. Comme job et category sont S 

deux modules, ils se trouvent naturellement dans le repertoire apps/ j! 
backend/modules. En les explorant tous les deux, il est important de 

remarquer que les repertoires tempi ates/ sont tous les deux vides tandis ™ 

que les fichiers d'actions le sont quasiment aussi. Le code suivant issu du ^ 

fichier actions. class. php du module job en temoigne. rt 

Contenu du fichier apps/backend/modules/job/actions/actions.class.php 

requi re_once di rname( FILE ) . '/■ ./l ib/jobGene rato reconfiguration, class. php' ; 

requi re_once di rname( FILE ) . '/■ ./l ib/jobCeneratorHel per. class .php' ; 

class jobActions extends autoDobActions 

{ 

} 

Comment tout cela peut-il fonctionner avec si peu de code ? En y regar- 
dant de plus pres, la classe jobActions n'etend pas sf Actions comme 
c'est le cas generalement, mais derive la classe autoJobActions. Cette 
classe existe bel et bien dans le projet mais se trouve dans un endroit un 
peu inattendu. Elle appartient en realite au repertoire cache/backend/ 
dev/modules/autoJob/ qui contient le veritable module d'administra- 
tion. 

Extrait du fichier cache/backend/dev/modules/autoJob/actions/actions.class.php 

class auto JobActions extends sfActions 
{ 

public function preExecuteO 
{ 

$thi s->configuration = new jobCeneratorConfiguration() ; 

if ( ! $thi s->getUser()->hasCredential ( 

$thi s->conf i gu rati on->getCredenti al s ($thi s->getActi onName () ) 

)) 
{ 

// ... 

Le choix de generer tout le module dans le cache de Symfony n'a pas ete 
decide au hasard. En effet, les sections suivantes du chapitre presentent 
toute la force du generateur d'administration, a savoir la configuration 
du module grace a un simple fichier YAML. N'importe quel change- 
ment dans ce dernier entrainera une regeneration de l'integralite du 
module et done des templates et des classes. C'est pour cette raison que 
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les modules ne se trouvent pas dans le repertoire de 1' application mais 
dans celui du cache. 



E 



Introduction au fichier de configuration generator.yml 

La maniere dont fonctionne le generateur de backoffice doit forcement 
rappeler quelques comportements connus. C'est en fait tres similaire a ce 
qui a deja ete presente au sujet des classes de formulaires et de modeles. 
A l'aide du schema de description de la base de donnees, Symfony 
genere le modele et les classes de formulaire. En ce qui concerne le gene- 
rateur de backoffice, l'integralite du module est configurable en editant 
le fichier config/generator.yml du module. Le code suivant presente le 
fichier par defaut genere avec le module j ob. 

Fichier de configuration apps/backend/modules/job/config/generator.yml 

generator: 

class: sfDoctrineGenerator 
param : 

model_class: JobeetJob 
theme: admin 
non_verbose_templates: true 
with_show: false 
singular: 
plural: 

route_prefix: jobeet_job 
with_doctrine_route: 1 

config: 

actions: ~ 

fields: ~ 

list: 

filter: ~ 

form: 

edit: 

new: 

Chaque fois que le fichier config/generator.yml est modifie, Symfony 
regenere le cache. Le renouvellement de ce dernier se produit bien sur 
automatiquement en environnement de developpement. En environne- 
ment de production, il doit etre vide manuellement. Les prochaines 
pages de ce chapitre montrent a quel point il est facile, rapide et intuitif 
de configurer et de personnaliser des modules construits grace au gene- 
rateur de backoffice. 
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Configurer les modules autogenics 
par Symfony 

Cette nouvelle section aborde la partie la plus importante du chapitre. II 
s'agit d'apprendre comment configurer un module auto genere a partir 
du fichier de configuration generator.yml. En effet, tous les elements 
qui composent les pages d'une interface d'administration sont editables 
et surchargeables grace a ce fichier. 

Organisation du fichier de configuration generator.yml 

Un module d'administration peut etre configure en editant toutes les 
sections se trouvant sous la cle config du fichier de configuration 
config/generator.yml. La configuration est organisee en sept sections 
distinctes : 

• acti ons definit la configuration par defaut des actions qui se trouvent 
dans la liste d'objets et dans les formulaires ; 

• f i el ds definit la configuration des differents champs d'un objet ; 

• list definit la configuration de la liste des objets ; 

• filter definit la configuration des filtres de recherche de la barre 
laterale de droite ; 

• form definit la configuration des formulaires d'ajout et de modifica- 
tion des objets ; 

• edit correspond a la configuration specifique pour la page d'edition 
d'un objet ; 

• new correspond a la configuration specifique pour la page de creation 
d'un objet. 

Toutes ces sections de configuration des modules seront presentees juste 
apres plus en detail avec des exemples concrets appliques au backoffice 
de l'application. Ce processus de personnalisation demarre par la confi- 
guration des titres de chaque page du module. 

Configurer les titres des pages des modules auto generes 

Changer le titre des pages du module category 

Pour l'instant, les titres des pages affiches au-dessus de la liste de resul- 
tats ou au-dessus des formulaires de creation et d'edition sont ceux qui 
ont ete generes par defaut par Symfony. lis sont bien evidemment tous 
modifiables tres simplement grace au fichier de configuration 



generator.yml. II suffit en effet d'ajouter a ce dernier une sous-section 
ti tl e aux cles 1 i st, new et edi t comme le montre le code ci-dessous. 

Contenu du fichier de configuration du module category apps/backend/modules/ 
category/conf ig/generator.yml 

confi g : 

actions: ~ 
fields: ~ 
list: 

title: Category Management 

filter: ~ 
form: ~ 
edit: 

title: Editing Category "%%name%%" 
new: 

title: New Category 

Le titre de la section edi t supporte des valeurs dynamiques. Les chaines 
de caracteres delimitees par %% sont remplacees par la valeur correspon- 
dante au nom de la colonne indiquee de la table. Ainsi, dans cet 
exemple, le motif %%name%% sera remplace par le nom de la categorie en 
cours de modification. 



Jobeet 



lobs Categories 

Figure 12-2 

Titre dynamique de I'ecran EDITING CATEGORY "DESIGN" 

d'edition d'une categorie 

Namp riocinn 



Configurer les titres des pages du module job 

Dans la foulee, il est possible d'en faire autant pour le module job en 
editant son fichier de configuration generator.yml. 

Contenu du fichier de configuration du module job apps/backend/modules/job/ 
conf ig/ generator.yml 

confi g : 

actions: ~ 
fields: ~ 
list: 

title: Dob Management 

filter: ~ 
form: 
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edit: 

title: Editing Job "%%company%% is looking for a %%position%%" 

new: 

title: Job Creation 

Comme le montre le nouveau titre de la section edit, les parametres 
dynamiques sont cumulables. Ici, le titre de la page d'edition d'une offre 
est compose du nom de la societe (%%company%%) et du type de poste pro- 
pose (%%position%%). 

Modifier le nom des champs d'une offre d'emploi 



Redefinir globalement les proprietes des champs du module 

Les differentes vues (list, new et edit) de chaque module sont compo- 
sees de « champs ». Un champ represente aussi bien le nom d'une 
colonne dans une classe de modele, qu'une colonne virtuelle. Ce concept 
est explique plus loin dans ces pages. La section fields permet de 
definir globalement l'ensemble des proprietes des champs du module. 

Configuration des champs du module job dans le fichier apps/backend/modules/ 
job/config/generator.yml 

config: 
fields: 

is activated: { label: Activated?, help: Whether the user 
has activated the job, or not } 

is„public: { label: Public? } 



Public? 



whether the job can also be published on affiliate websites or not. 



Email job@example.com 
X Delete □ Cancel ( Save ) 



Figure 12-3 

Configuration des 
champs is_activated 
et is_public 



Lorsqu'ils sont declares directement dans la section fields, les champs 
sont redefinis globalement pour toutes les autres vues. Ainsi, le 1 abel du 
champ is_public sera le meme quelle que soit la vue affichee : list, 
edi t ou new. 



Surcharger localement les proprietes des champs du module 

Toutefois, il est frequent de vouloir des intitules differents pour chaque 
vue, notamment entre la page de liste et les formulaires. Toute la confi- 
guration du generateur d'administration repose sur un principe d'heri- 
tage en cascade, ce qui permet de pouvoir redefinir certaines valeurs a 
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plusieurs niveaux. Par exemple, si Ton souhaite changer un label uni- 
quement pour la liste d'objet, il suffit simplement de creer une nouvelle 
section f i el ds juste en dessous de la cle 1 i st. 

Redefinition du label d'un champ pour la liste dans le fichier apps/backend/ 
modules/job/config/generator.yml 

config: 
list: 
fields: 

is_pub"lic: { label: "Public? (label for the list)" } 

La partie suivante explique le principe de configuration en cascade du 
generateur d'administration. 

Comprendre le principe de configuration en cascade 

N'importe quelle configuration definie sous la section principale fields 
peut etre surchargee pour les besoins d'une vue specifique. Les regies de 
reconfiguration sont les suivantes : 

• les sections new et edit heritent de form, qui herite lui-meme de 
fields ; 

• la section list herite de f i elds; 

• la section f i 1 ter herite de f i el ds. 

Pour les sections form (form, edit et new), les options label et help sur- 
charged celles definies dans les classes de formulaire. 

Configurer la liste des objets 

Les parties qui suivent expliquent l'ensemble des possibilites de configu- 
ration de la vue liste des modules auto generes. Parmi toutes ces direc- 
tives de configuration figurent entre autres la declaration des 
informations de l'objet a afficher, la definition du nombre d'objets par 
page, l'ordre par defaut de la liste, les actions par lot, etc. 

Definir la liste des colonnes a afficher 

Colonnes a afficher dans la liste des categories 

Par defaut, les colonnes affichees de la vue liste sont toutes celles du 
modele, dans l'ordre du schema de definition de la base de donnees. 
Loption display surcharge la configuration par defaut en definissant, 
dans l'ordre d'apparition, la liste des colonnes a afficher dans la liste. 



Redefinition des colonnes de la vue liste du module category dans le fichier de 
configuration apps/backend/modules/category/config/generator.yml 

config: 
list: 

title: Category Management 
display: [=name, slug] 

Le signe = qui precede le nom de la colonne est une convention dans le 
framework Symfony qui permet de convertir le texte en un lien cliquable 
qui mene l'utilisateur au formulaire d'edition de l'objet. 
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Figure 12-4 

Rendu de la page 
d'accueil du module 
d'administration des 
categories 



Liste des colonnes a afficher dans la liste des offres 

La configuration des colonnes du tableau de la vue liste du module job 
est exactement la meme comme le demontre le code ci-apres. 

Definition des colonnes de la vue liste du module job dans le fichier apps/backend/ 
modules/job/config/generator.yml 

config: 
list: 

title: Dob Management 

display: [company, position, location, url , is_activated, email] 

Desormais, la nouvelle liste se limite au nom de la societe, le type de 
poste, la localisation de l'offre, Furl, le statut et l'email de contact. 



Configurer le layout du tableau de la vue liste 

La vue liste peut etre affichee avec differents gabarits. Par defaut, c'est le 
layout tabulaire (tabular), qui signifie que chaque valeur d'une colonne 
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est presentee dans sa propre colonne du tableau. II serait neanmoins plus 
avantageux d'avoir recours au layout lineaire (stacked), qui est le second 
gabarit disponible par defaut. 

Configuration du layout stacked pour le module job dans le fichier apps/backend/ 
modules/job/config/generator.yml 

config: 
list: 

title: Job Management 
layout: stacked 

display: [company, position, location, url , 
is_activated, email] 

params: | 

%%i s acti vated%% <smal l>%%category id%%</smal 1 > 
- %%company%% 

(<em>%%email%%</em>) is looking for a %%=position%% 

(%%location%%) 

Avec le layout lineaire, chaque objet est represente sous la forme d'une 
chaine de caracteres unique, definie grace a l'option params. L' option 
display reste necessaire dans la mesure oil elle determine les colonnes 
grace auxquelles 1'utilisateur peut ordonner la liste des resultats. 

Declarer des colonnes « virtuelles » 

Avec cette configuration, le motif %%category_id%% sera remplace par la 
cle primaire de la categorie a laquelle l'offre est associee. Cependant, il 
est beaucoup plus pertinent et significatif d'afficher le nom de la cate- 
goric Quelle que soit la notation %% utilisee, la variable n'a pas besoin de 
correspondre a une colonne reelle du schema de definition de la base de 
donnees. Le generateur de backoffice doit en effet etre capable de 
trouver un accesseur associe dans la classe de modele. 

Afin d'afficher le nom de la categorie, il est possible de declarer une 
methode getCategoryNameO dans la classe de modele JobeetJob, puis de 
remplacer %%category_id%% par %%category_name%%. Or, la classe 
JobeetJob dispose deja d'une methode getJobeetCategoryO qui 
retourne 1' objet categorie associe. De ce fait, en utilisant le motif 
%%jobeet_category%%, le nom de la categorie s'affiche dans la liste 
d'offres d'emploi car la classe DobeetCategory implements la methode 
magique toStri ng() qui convertit l'objet en une chaine de caracteres. 

Code a remplacer dans le fichier apps/backend/modules/job/config/generator.yml 

%%is_activated%% <small>%%jobeet_category%%</small> - 

j %%company%% 

(<em>%%email%%</em>) is looking for a %%=position%% 
(%%location%%) 
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looking for a Web Developer (Paris, France) 


f Edit 
X Delete 


a 


■ Design - Extreme Sensio (Job@example.com) is looking 
for a Web Designer (Paris, France) 


f Edit 
X Delete 


□ 


Programming - Sensio Labs (Job@example.com) is 
looking for a Web Developer (Paris, France) 


/ Edit 
X Delete 


i — i 







Category id 
Type 



□ is empty 



Company 
Logo 



□ is empty 



□ is empty 



Figure 12-5 

Ajout de la categorie 
pour chaque objet 



Definir le tri par defaut de la liste d'objets 

Un administrateur preferera certainement voir les dernieres offres 
d'emploi postees sur la premiere page. L'ordre des enregistrements dans 
la liste est configurable grace a l'option sort de la section list comme le 
montre le code ci-dessous. 

Definition de l'ordre des objets dans le tableau de la vue liste dans le fichier apps/ 
backend/modules/job/config/generator.yml 

config: 
list: 

sort: [expi res_at , desc] 

La premiere valeur du tableau sort correspond au nom de la colonne sur 
laquelle le tri effectue, tandis que la seconde definit le sens. La valeur 
desc determine un ordre descendant, e'est-a-dire du plus grand au plus 
petit (ou de Z a A pour les chaines, ou bien du plus recent au plus vieux 
avec les dates). Pour obtenir un ordre ascendant (par defaut), il suffit de 
d'indiquer la valeur asc. 

Reduire le nombre de resultats par page 

Par defaut, la liste est paginee et chaque page contient 
20 enregistrements. Cette valeur est bien sur editable grace a l'option 
max_per_page de la section list. 
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Definition du nombre d'enregistrements par page dans le fichier apps/backend/ 
modules/job/config/generator.yml 

confi g : 
list: 

max_per_page: 10 



Figure 12-6 

Pagination de la liste 
d'objets 
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Configurer les actions de lot d'objets 

Le generateur de backoffice de Symfony integre nativement la possibi- 
lite d'executer des actions sur un lot d'objets selectionnes dans le tableau 
de la vue liste. Le gestionnaire n'en a pas veritablement besoin, e'est 
pourquoi la premiere partie explique comment les desactiver. En 
revanche, la seconde partie presente comment configurer de nouvelles 
actions de lot pour le module job. 

Desactiver les actions par lot dans le module category 

La vue liste permet d'executer une action sur plusieurs objets en meme 
temps. Ces actions par lot ne sont pas necessaires pour le module 
category, e'est pourquoi le code montre la maniere de les retirer a l'aide 
d'une simple configuration du fichier generator.yml. 

Suppression des actions de lot dans le fichier apps/backend/modules/category/ 
conf ig/ generator.yml 

confi g : 
list: 

batch actions: {} 

Loption batch_actions definit la liste des actions applicables sur un lot 
d'objets Doctrine. Indiquer explicitement un tableau vide en guise de 
valeur permet de supprimer cette fonctionnalite. 
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Figure 12-7 

Liste des categories apres 
suppression des actions 
par lot d'objets 



Ajouter de nouvelles actions par lot dans le module job 

Par defaut, chaque module dispose d'une action de suppression par lot 
generee automatiquement par le framework. En ce qui concerne le 
module job, il serait utile de pouvoir etendre la validite de quelques objets 
selectionnes pour 30 jours supplementaires, grace a une nouvelle action. 

Ajout de la nouvelle action extends dans le fichier apps/backend/modules/job/ 
config/generator.yml 

config: 
list: 

batch_actions: 
_de1ete: 
extend: 

Toutes les actions commencant par un tiret souligne (underscore) sont 
des actions natives fournies par le framework. En rafraichissant le navi- 
gateur, la liste deroulante accueille a present Taction extend mais Sym- 
fony lance une exception indiquant qu'une nouvelle methode 
executeBatchExtendO doit etre creee. 

Methode executeBatchExtendO a ajouter au fichier apps/backend/modules/job/ 
actions/actions.class.php 

class jobActions extends autoDobActions 
{ 

public function executeBatchExtend(sfWebRequest $request) 
{ 

$ids = $request->getParameter('ids') ; 
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$q = Doctrine Query: :create() 
->from('3obeetDob j') 
->whereln(' j.id' , $ids); 

foreach ($q->execute() as $job) 
{ 

$job->extend(true) ; 

} 

$this->getUser()->setF1ash( ' notice' , 'The selected jobs 
have been extended successfully.'); 

$this->redirect('@jobeet job') ; 

} 

} 

Bien que la comprehension de ce code ne pose pas de difficulte particu- 
liere, quelques explications supplementaires s'imposent. La liste des cles 
primaires des objets selectionnes est stockee dans le parametre ids de 
l'objet de requete. Ce tableau d'identifiants uniques a ete transmis en 
POST lors de la soumission du formulaire. La variable $ids est ensuite 
transmise a la requete Doctrine qui se charge de recuperer et d'hydrater 
tous les objets correspondant a cette liste d'identifiants. 

Lappel a la methode execute () sur l'objet Doctrine_Query retourne un 
objet Doctrine_Collection contenant toutes les offres JobeetJob corres- 
pondantes recuperees dans la base de donnees. Pour chaque offre 
d'emploi, l'appel a la methode extend () permet de prolonger la duree de 
vie de l'objet pour une duree de 30 jours supplementaires. 

Enfin, un nouveau message de feedback est ecrit dans la session de l'uti- 
lisateur afin de lui informer que les offres selectionnees ont bien ete pro- 
longees apres sa redirection. 

Le parametre true de la methode extend () permet de contourner la 
verification de la date d'expiration. Le code suivant implemente cette 
nouvelle fonctionnalite. 

Edition de la methode extend() de la classe JobeetJob dans le fichier lib/model/ 
doctrine/JobeetJob.class.php 

: class JobeetJob extends BaseJobeetJob 
{ 

public function extend($force = false) 

{ 

if (!$force && ! $this->expi resSoonO) 
{ 

return false; 

} 

$this->setExpiresAt(date('Y-m-d' , time() + 86400 * 
sfConfig: :get('app_active_days'))) ; 



$thi s->save() ; 
return true; 

} 

// ... 
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Configurer les actions unitaires pour chaque objet 

Le tableau de la vue liste contient une colonne additionnelle destinee aux 
actions applicables unitairement sur chaque objet. Par defaut, Symfony 
introduit les actions d'edition et de suppression d'un enregistrement, 
mais il est evidemment possible d'en aj outer de nouvelles en editant le 
fichier de configuration du module. 



Supprimer les actions d'objets des categories 

En considerant que le lien sur le titre de la categorie suffise pour acceder 
au formulaire d'edition et que la suppression d'une categorie soit inter- 
dite, les actions d'objet n'ont plus veritablement de raison de persister. 
La configuration suivante retire completement la derniere colonne du 
tableau de categories. 

Suppression des actions d'objets dans le fichier apps/backend/modules/category/ 
config/generator.yml 

config: 
list: 

object actions: {} 

De la meme maniere que pour les actions par lot, specifier un tableau 
vide comme valeur a l'option object^actions permet de retirer les 
actions des objets du tableau. 
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Ajouter d'autres actions pour chaque offre d'emploi 

Pour le module job, il convient de conserver les actions d'edition et de 
suppression pour chaque item du tableau. Le code ci-dessous montre 
comment ajouter une nouvelle action extend pour chaque objet. Cette 
derniere permet d'etendre la duree de vie d'une offre de maniere unitaire 
au simple clic sur le lien cree par Symfony. 

Ajout de la nouvelle action d'objet extend au fichier apps/backend/modules/job/ 
config/generator.yml 

config: 
list: 

object^actions : 
extend: 
_edit: 
_delete: 

Pour fonctionner completement, cette action doit etre accompagnee de 
la declaration d'une methode executeListExtendO dans la classe 
d'actions. Celle-ci doit implementer la logique necessaire a la prolonga- 
tion de la duree de vie d'une offre comme le presente le code suivant. 

Ajout de la methode executeListExtendO au fichier apps/backend/modules/job/ 
actions/actions.class.php 

class jobActions extends autoJobActi ons 
{ 

public function executeListExtend(sfWebRequest $request) 
{ 

$job = $this->getRoute()->getObject() ; 
$job->extend(true) ; 

$this->getUser()->setFlash( ' notice' , 'The selected jobs 
have been extended successfully.'); 

$this->redirect('@jobeet job') ; 

} 

// ... 

} 

Configurer les actions globales de la vue liste 

Pour l'instant, il est possible de creer des liens vers des actions pour la liste 
entiere ou bien pour un seul enregistrement du tableau. L'option actions 
definit la liste des actions qui ne sont pas directement en relation avec les 
objets, c'est le cas par exemple de la creation d'un nouvel objet. 



Jobeet 



lobs Categories 



JOB MANAGEMENT 

The selected jobs have been extended successfully. 
□ Company Position Location Url Activated? Email Actions 



B * programming - Sensio Labs {job@example.com) is 
looking for a Web Developer (Paris, France) 



Extend 
* Edit 
X Delete 



Category id ' I %\ 

Type 



□ is empty 



C Design - Extreme Sensio (JobiSiexample.com) is looking Extend 
for a Web Designer (Paris, France) Edit 



Company 



□ is empty 



Figure 12-9 

Ajout de Taction extend 
pour chaque objet 



Dans Jobeet, ce sont les utilisateurs qui postent de nouvelles offres. Les 
administrateurs n'en ont pas la necessite, e'est pourquoi le lien de crea- 
tion d'un nouvel objet peut etre supprime. En revanche, les administra- 
teurs doivent avoir la possibilite de purger la base de donnees des offres 
expirees de plus de 60 jours. 

Ajout d'une nouvelle action globale deleteNeverActivated dans le fichier apps/ 
backend/modules/job/config/generator.yml 

config: 
list: 
actions : 

deleteNeverActivated: { label: Delete never activated jobs } 

Jusqu'a maintenant, toutes les actions globales de la vue liste etaient 
declarees avec le symbole « tilde » (~), ce qui signifie que Symfony confi- 
gure Taction automatiquement. Chaque action peut etre personnalisee 
en definissant un tableau de parametres. L'option label surcharge i'inti- 
tule automatiquement genere par le framework. Par defaut, Faction exe- 
cutee lorsque Ton clique sur le lien est le nom de Faction prefixe par 
list. Le code ci-dessous montre Implementation de Faction globale 
deleteNeverActivated pour le module job. 

Implementation de la methode NstDeleteNeverActivated dans le fichier apps/ 
backend/modules/job/actions/actions.class.php 

class jobActions extends autoJobActions 
{ 

public function executeListDeleteNeverActivated(sfWebRequest 
$ request) 
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$nb = Doctrine: :getTable(' JobeetDob')->cleanup(60) ; 

if ($nb) 
{ 

$this->getUser()->setFlash('notice' , sprintf('%d never 
activated jobs have been deleted successfully.', $nb)); 
} 

el se 
{ 

$thi s->getUser()->setFlash(' notice ' , 'No job to delete.'): 

} 



$this->redirect('@jobeet job') ; 



} 

// 



Cette action nest guere complexe a comprendre. La premiere ligne du 
corps de la methode fait appel a la methode cleanupO qui se charge de 
supprimer de la base de donnees toutes les offres expirees depuis plus de 
60 jours. Cette methode a ete implementee lors du precedent chapitre. 
Elle prend en parametre le nombre de jours succedant la date d'expira- 
tion de l'offre et retourne le nombre d'enregistrements effaces de la base 
de donnees. Enfin, en fonction du nombre d'objets effaces, un message 
flash est fixe dans la session de l'utilisateur avant de le rediriger vers la 
page d'accueil du module d'administration. 

La reutilisation de la methode cleanupO est ici un exemple particuliere- 
ment demonstratif des avantages du motif de conception MVC. 

Le nom de la methode a ecrire risquera d'etre trop peu explicite et fasti- 
dieux a ecrire. Dans ce cas, il est possible de remplacer le nom genere par 
defaut. 



Figure 12-10 

Ajout de fonctionnalites 
globales a la vue liste 





Fiuijiariifriing — company iuh gooigmaBnpnxorni tb 

looking for a Web Developer (Paris, France) 


* Edit 
X Delete 


□ 


Programming - Company 105 (Jobt3example.com) is 
looking for a Web Developer (Paris, France) 


Extend 

Edit 

Delete 


□ 


Programming - Company 106 (job@example.com) is 
looking for a Web Developer (Paris, France) 


Extend 
* Edit 
X Delete 


3G results (page 1/4) 





Choose an action ^go) Delete never activated jobs 



Token 

Public? 
Activated? 

Email 
Expires at 



□ is empty 
yes or no 1 

yes or no t \ 

whether the user has activated th 



□ is empty 



fro m r ni/m/r~ 

to : 



242 



Le nom de Faction a utiliser peut aussi etre redefini afin de le simplifier. 
II suffit alors d'ajouter un parametre action dans la declaration de 
Taction globale comme le presente le code ci-dessous. 

deleteNeverActivated: { label: Delete never activated jobs, 
action: foo } 



Optimiser les requetes SQL de recuperation des 
enregistrements 

En affichant l'onglet SQL de la barre de deboguage de Symfony, on cons- 
tate ici que la liste a besoin d'executer 14 requetes SQL pour afficher la 
liste des offres d'emploi. Or, parmi ces 14 requetes, il y en a 10 qui rem- 
plissent le meme besoin : recuperer le nom de la categorie associee a 
l'enregistrement. Cet exemple sous-entend clairement le manque d'une 
jointure entre les relations jobeet_job et jobeet_category qui permet- 
trait de selectionner a la fois les offres et leur categorie respective a l'aide 
d'une seule et meme requete SQL. 



SQL queries 



conflg 



logs 



322 ms 14 



SET NAMES 'Utf8' 

SELECT COUNTC) FROM 'jobeet Job' 

SELECT jobeet_category,ID. jobeet_category.NAME. jobeet_category.SLUG FROM 'jobeet_category' 

SELECT jobeeljob. ID, jobeet Job. CATEGORY ID, jobeelJob.TYPE. jobeet Job.COMPANY, jobeeljob. LOGO, jobeetJob.URL. jobeet Job. POSITION, 
jobeet Job.LOCATION. jobeet lOb.DESCRIPTION, jobeet Job.HOW_TO„APPLY. jobeet job.TOKEN. jobeet Job.lSJ=UBLIC, jobeet Job.lS_ACTIVATED, 
jobeeljob. EMAIL, jobeet Job.EXPIRES_AT, Jobeet_Job.CREATED_AT. jobeet Job.UPDATED_AT FROM 'jobeet Job' LIMIT 10 
SELECT jobeet_category,ID. jobeet_category.NAME. jobeet_category.SLUG FROM jobeet_category' WHERE jobeet_category,ID=14 LIMIT 1 
jobeet_category.NAME. jobeet_category.SLUG FROM '|obeet_category' WHERE )obeet_category,ID=13 LIMIT 1 
|obeet_category.NAME, jobeet_category.SLUG FROM 'jobeet_category' WHERE jobeet_category.lD=14 LIMIT 1 
jobeeLcategory.NAME, jobeet_category.SLUG FROM 'jobeet_category' WHERE jobeet_category,ID=14 LIMIT 1 
|obeet_category.NAME. jobeet_category.SLUG FROM 'jobeet_category' WHERE jobeet_category,ID=14 LIMIT 1 
iobeeLcategotv.NAME, jobeeLcategory.SLUG FROM 'jobeet_categoty' WHERE jobeet_category.lD=14 LIMIT 1 
jobeeLcategory.NAME. jobeet_category.SLUG FROM 'jobeet_category' WHERE jobeet_category,ID=14 LIMIT 1 
|obeet_category.NAME. jobeet_category.SLUG FROM 'jobeet_category' WHERE jobeet_category,ID=14 LIMIT 1 
iobeet_category.NAME. jobeet_category.SLUG FROM iobeeLcategory' WHERE jobeet_category.lD=14 LIMIT 1 
iobeet cateqorv.NAME, iobeet cateqorv.SLUG FROM ' obeet cateqory' WHERE jobeet cateqorv.lD=14 LIMIT 1 



SELECT jobeet_category 
SELECT jobeet_category 
SELECT jobeet_category 
SELECT jobeet_category 
SELECT jobeet_categorv 
SELECT jobeet_category. 
SELECT jobeet_category 
SELECT jobeet„category 
SELECT jobeet_category 



Programming - Sensio Labs (job@iexample.eom) is 
looking for a Web Developer (Paris, France) 



□ Exteiid 
* Edit yl 
X Delete 



pe 



□ is empty 



Figure 12-11 

Detail des requetes SQL 
generees pour afficher la 
liste d'objets 



Par defaut, le generateur de backoffice utilise la methode Doctrine la plus 
simple pour recuperer une liste d'enregistrements. De ce fait, lorsque des 
objets sont en relation, l'ORM est oblige d'effectuer les requetes adequates 
pour les retrouver et hydrater l'objet associe a la demande. 

Pour eviter ce comportement et cette perte de performance, l'option 
table_method permet de surcharger la methode Doctrine utilisee par 
defaut par le framework pour generer la liste de resultats. Des lors, il est 
possible de declarer une nouvelle methode dans le modele qui imple- 
mente la jointure entre les deux tables. 

Les deux listings de code suivants expliquent comment configurer 
l'emploi d'une nouvelle methode du modele pour la recuperation des 
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SQL queries 



enregistrements et de quelle maniere elle doit etre implementee pour le 
module job. 

Surcharge de la methode de recuperation des enregistrements dans le fichier apps/ 
backend/modules/job/config/generator.yml 

confi g : 
list: 

tabl e method : retrieveBackendJobLi st 

II ne reste alors plus qua implementer cette nouvelle methode 
retri eveBackendJobLi st dans la classe Jobeet JobTabl e qui se trouve 
dans le fichier lib/model /doctri ne/DobeetJobTable.cl ass. php. 

Implementation de la methode retrieveBackendJobList dans le fichier lib/model/ 
doctrine/JobeetJobTable.class.php 

class Jobeet JobTabl e extends Doctri ne_Tabl e 
{ 

public function retrieveBackendJobList(Doctrine Query $q) 
{ 

$rootA1ias = $q->getRootAl ias() ; 
$q->1eft3oin($rootA1ias . ' . JobeetCategory c'); 
return $q; 

} 

// ... 

Cette methode retri eveBackendJobLi st() re9oit un objet 
Doctri ne_Query en parametre auquel elle ajoute la condition de jointure 
entre les tables jobeet_categoy et jobeet_job dans le but de creer auto- 
matiquement chaque objet JobeetJob et JobeetCategory. Maintenant, 
grace a cette requete optimisee, le nombre de requetes SQL executees 
pour generer la vue liste tombe a 4 comme l'atteste l'onglet SQL de la 
barre de deboguage de Symfony. 



config 



logs 



34457 KB 



281 ms 



4 



SET NAMES -Utf8' 

SELECT COUNT(-) FROM jobeet Job' 

SELECT jobeet_category,ID, jobeet_category.NAME, jobeet_calegory.SLUG FROM 'jobeet_category' 

SELECT jobeet job. ID, jobeet Job.CATEGORYJD. jobeetJob.TYPE. jobeet Job. COMPANY, jobeetjob.LOGO, jobeet Job. URL. jobeet Job. POSITION, 
jobeet Job.LOCATiON. jobeet job.DESCRIPTION. jobeet Job.HOW_TO_APPLY. jobeet jpb.TOKEN. jobeet Job.lS„PUBLIC, jobeet Job.lS_ACTIVATED, 
jobeet Job. EMAIL. JobeetJob.EXPIRES_AT,jobeetJob.CREATED_AT. jobeet Job. UPDATED_AT. jobeet.category.ID, jobeet category NAME, 
jobeet_category.SLUG FROM Jobeetjob' LEFT JOIN jobeet_category ON (jobeet Job.CATEGORYJD=jobeet_category.lD) LIMI T10 



lobs Categories 



Figure 12-12 

Detail des requetes SQL 
generees pour afficher la 
liste d'objets apres 
optimisation 



JOB MANAGEMENT 



Company Position Location Url Activated? Email ActionEategory id 



programming - Sensio Labs (job@example.com) is 
looking for a Web Developer (Paris, France) 
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. Delete 



□ is empty 
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La configuration de la vue list des modules category et job s'acheve ici. 
Les deux modules disposent a present chacun d'une vue list entierement 
fonctionnelle, paginee et adaptee aux besoins des administrateurs de 
l'application. II est desormais temps de s'interesser a la personnalisation 
des formulaires qui composent les vues new et edit. 



Configurer les formulaires des vues de 
saisie de donnees 

La configuration des vues de formulaires se decompose en trois sections 
distinctes dans le fichier generator. yml : form, edit et new. Toutes pos- 
sedent les memes possibilites de configuration dans la mesure oil la sec- 
tion form peut etre surcharged dans les deux autres sections. 

Les parties qui suivent expliquent comment configurer les formulaires 
qui permettent de creer et d'editer les objets Doctrine en vue de leur 
serialisation dans la base de donnees. La configuration de ces vues inter- 
vient a differents niveaux tels que l'ajout ou la suppression de champs, la 
modification de leurs proprietes respectives, le choix d'une classe de for- 
mulaire personnalisee a la place de celle par defaut. . . 

Configurer la liste des champs a afficher dans les 
formulaires des offres 

De la meme maniere que pour la vue list, il est possible de changer le 
nombre et l'ordre des champs affiches dans les formulaires grace a 
l'option display. Comme le formulaire affiche est defini par une classe, 
il est recommande de ne pas tenter de supprimer de champ dans la 
mesure ou cela risque de conduire a des erreurs de validation inatten- 
dues. Le code ci-dessous explique comment utiliser l'option display 
pour configurer la liste des champs a afficher dans le formulaire. Cette 
option a la particularite de faciliter l'ordonnancement des champs par 
groupes d'information de meme nature. 

Configuration des formulaires dans le fichier apps/backend/modules/job/config/ 
generator.yml 

config: 
form: 
displ ay: 

Content: [category id, type, company, logo, url , position, 
location, description, how to apply, is public, email] 

Admin: [generated token, is activated, expires at] 
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La configuration ci-dessus definit deux groupes d'informations (Content 
et Admin), dont chacun contient un sous-ensemble des champs du for- 
mulaire. La capture d'ecran ci-dessous montre le rendu obtenu a partir 
de cette configuration du formulaire. 



EDITING JOB "SENSIO LABS IS LOOKING FOR A WEB DEVELOPER" 



Figure 12-13 

Rendu du formulaire 
d'edition d'une offre 
d'emploi 



Content 

Category 

Type 
Company 

Company logo 

Url 



Programming i i | 

® Full time C Part time C Freelance 



Sensio Labs 



http://www.sensiolabs.com 



Browse 



Les colonnes du groupe d'informations Admin ne s'affichent pas encore 
dans le navigateur car elles ont ete retirees de la definition du formulaire 
de gestion d'une offre. Elles apparaitront plus tard dans ce chapitre 
lorsqu'une classe de formulaire d'offre d'emploi personnalisee sera 
definie pour l'application backoffice. 

Le generateur d'administration dispose d'un support natif pour les rela- 
tions plusieurs a plusieurs (many to many). Sur le formulaire de manipu- 
lation d'une categorie, il existe un champ pour le nom et pour le slug, 
ainsi qu'une liste deroulante pour les partenaires associes. Editer cette 
relation dans cette page n'a pas veritablement de sens, c'est pourquoi elle 
peut etre retiree du formulaire comme le montre la configuration de la 
classe de formulaire ci-dessous. 

Configuration de la liste des champs du formulaire de categorie dans le fichier lib/ 
form/doctrine/JobeetCategoryForm.class.php 

class JobeetCategoryForm extends BaseJobeetCategoryForm 
{ 

public function configureO 
{ 

unset($this['created at'] , $this[' updated at'] , 
$thi s [ ' jobeet af f i 1 i atesj i st ' ] ) ; 

} 

} 
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La section suivante aborde la notion de champs virtuels, c'est-a-dire des 
champs supplementaires qui n'appartiennent pas a la definition de base 
des widgets de la classe de formulaire. 

Ajouter des champs virtuels au formulaire 

Dans l'option display du formulaire d'offre d'emploi figure le champ 
_generatecLtoken dont le nom commence par un underscore. Cela 
signifie que le rendu de ce champ est pris en charge par un template par- 
tiel nomme _generated_token.php. Le contenu de ce fichier a creer est 
presente dans le bloc de code ci-dessous. 

Contenu du template partiel dans le fichier apps/backend/modules/job/templates/ 
_generated_token.php 

<di v class="sf_admi n_form_row"> 
<1 abel >Token</l abel > 

<?php echo $form->getObject()->getToken() ?> 

</di v> 

Un partial a acces au formulaire courant ($form), et done a l'objet associe 
via la methode getObject() appliquee sur cet objet de formulaire. Le 
rendu du champ virtuel peut aussi etre delegue a un composant en pre- 
frxant son nom par un tilde. 

Redefinir la classe de configuration du formulaire 

Comme le formulaire sera manipule par les administrateurs, quelques 
informations nouvelles ont ete ajoutees en complement par rapport au 
formulaire de l'application frontend. Pour l'instant, certaines d'entre 
elles n'apparaissent pas sur le formulaire puisqu'elles ont ete supprimees 
dans la classe JobeetJobForm. 

Implementer une nouvelle classe de formulaire par defaut 

Afin d'obtenir differents formulaires entre les applications frontend et 
backend, il est necessaire de creer deux classes separees, dont une inti- 
tulee BackendJobeetJobForm qui etend la classe JobeetJobForm. Comme 
les champs caches ne sont pas les memes dans les deux formulaires, la 
classe JobeetJobForm doit etre remaniee legerement afin de deplacer 
l'instruction unset () dans une methode qui sera redefinie dans 
Backend JobeetJobForm. 



Contenu de la classe JobeeUobForm dans le fichier lib/form/doctrine/ 
JobeeUobForm.dass.php 

class JobeetJobForm extends BaseJobeetJobForm 
{ 

public function configureO 
{ 

$this->removeFieldsO ; 

$thi s->validatorSchema[ ' email '] = new sfVal i datorEmai 1 () ; 
// ... 

} 

protected function removeFieldsO 
{ 

unset ( 

$this['created_at'] , $this[' updated at'] , 
$this['expires at'] , $this['is activated'] , 
$this[' token'] 

); 

} 

} 

Contenu de la classe BackendJobeetJobForm dans le fichier lib/form/doctrine/ 
BackendJobeetJobForm.class.php 

class BackendJobeetJobForm extends JobeetJobForm 
{ 

public function configureO 
{ 

parent: : configureO ; 

} 

protected function removeFieldsO 
{ 

unset ( 

$thi s[' created at'] , $thi s[ 'updated at'] , 
$this[' token'] 

); 

} 

} 

A present, la classe de formulaire par defaut utilisee par le generateur 
d'administration peut etre surcharged grace au parametre class du 
fichier de configuration generator.yml. Avant de rafraichir le naviga- 
teur, le cache de Symfony doit etre vide afin de prendre en compte la 
nouvelle classe creee dans le fichier d'auto chargement de classes. 



Modification du nom de la classe par defaut pour les formulaires de I'application 
backend dans le fichier apps/backend/modules/job/config/generator.yml 

config : 
form : 

class: Backend JobeetJobForm 

Le formulaire de modification possede neanmoins un leger inconvenient. 
La photo courante telechargee de l'objet n'est affichee nulle part sur le for- 
mulaire, et il est impossible de forcer la suppression de l'actuelle. 

Implementer un meilleur mecanisme de gestion des photos des 
offres 

Le widget sfWidgetFormlnputFileEdi table apporte des capacites sup- 
plementaires d'edition de fichier par rapport au widget classique de tele- 
chargement de fichier. Le code suivant remplace le widget actuel du 
champ logo par un widget de type sfWidgetFormlnputFileEdi table, 
afin de permettre aux administrateurs de faciliter la gestion des images 
telechargees pour chaque offre. 

Modification du widget du champ logo dans le fichier lib/form/doctrine/ 
BackendJobeeU obForm .class, php 

class BackendJobeetJobForm extends JobeetJobForm 
{ 

public function configure() 
{ 

parent: :configure() ; 

$this->widgetSchema['logo'] = new sfWidgetFormInputFileEditab1e(array( 
'label' => 'Company logo', 

'file src' => '/uploads/jobs/' .$this->getObject()->getLogo() , 

'is image' => true, 

'edit mode' => !$this->isNew() , 

'template' => '<div>%fi1e%<br />%input%<br />%delete% %del ete 1 abel %</d 

)); 

$this->va"lidatorSchema['logo delete'] = new sfVal idatorPass() ; 

} 

// ... 

} 

Le widget sfWidgetFormlnputFileEdi table prend plusieurs options en 
parametres pour personnaliser ses fonctionnalites et son rendu dans le 
navigateur : 

• f i 1 e_s rc determine le chemin web vers le fichier courant ; 

• i s_i mage indique si oui ou non le fichier doit etre affiche comme une 
image ; 



• edit_mode specific si le formulaire est en mode d'edition ou s'il ne 
Test pas ; 

• wi th_del ete permet d'ajouter ou non une case a cocher pour forcer la 
suppression du fichier ; 

• tempi ate definit le gabarit HTML pour le rendu du widget. 
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Figure 12-14 Rendu du widget de modification de telechargement de fichier 



L'apparence du generateur de backoffice peut facilement etre personna- 
lisee dans la mesure ou les templates generes definissent un nombre 
important de classes CSS et d'attributs id. Par exemple, le champ logo 
peut etre mis en forme en utilisant la classe CSS 
sf_admi n_form_fie1d_logo. Chaque champ du formulaire dispose de sa 
propre classe relative au type de widget, telles que sf_admi n_text ou 
sf„admi n_bool ean. 

L'option edit_mode utilise la methode isNew() de l'objet 
sfDoctrineRecord. Elle retourne true si l'objet modele du formulaire est 
nouveau (creation) et false dans le cas contraire (edition). Cette 
methode est une aide indeniable lorsque le formulaire requiert des wid- 
gets ou des validateurs qui dependent du statut de l'objet embarque. 



Configurer les filtres de recherche de la vue 
liste 

Configurer les filtres de recherche est sensiblement similaire a configurer 
les vues de formulaire. En realite, les filtres sont tout simplement des 
formulaires. Ainsi, comme avec les formulaires, les classes de filtre ont 
ete automatiquement generees par la tache doctrine: build-all, mais 
peuvent egalement etre reconstruites a l'aide de la tache 
doctrine: build-filters. 

Les classes des formulaires de filtre sont situees dans le repertoire 1 i b/ 
filter, et chaque classe de modele dispose de sa propre classe de filtre 
(jobeetJobFormFilter pour JobeetJob). 

Supprimer les filtres du module de category 

Comme le module de gestion des categories ne necessite guere de filtres, 
ces derniers peuvent etre desactives dans le fichier de configuration 
generator. yml comme le montre le code ci-dessous. 

Suppression de la liste de filtres du module category dans le fichier apps/backend/ 
modules/category/config/generator.yml 

config : 
filter: 

class: false 

Configurer la liste des filtres du module job 

Par defaut, la liste de filtres permet de reduire la selection des objets en 
agissant sur toutes les colonnes de la table. Or, tous les filtres ne sont pas 
pertinents, c'est pourquoi certains d'entre eux peuvent etre retires pour 
les offres d'emploi. 

Modification de la liste de filtres du module job dans le fichier apps/backend/ 
modules/job/config/generator.yml 

filter: 

display: [category id, company, position, description, 
is activated, is public, email, expires at] 

Tous les filtres sont optionnels. De ce fait, il n'y a aucun besoin de sur- 
charger la classe de formulaire de filtres pour configurer les champs a 
afficher. 
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Figure 12-15 

Rendu de la liste des 
filtres apres configuration 
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Personnaliser les actions d'un module 
autogenere 

Lorsque la configuration ne suffit plus, il est toujours possible d'ajouter 
de nouvelles methodes a la classe des actions, comme eela a deja ete 
explique avec la prolongation de la duree de vie d'une offre d'emploi. Par 
ailleurs, toutes les actions autogenerees par le generateur de backoffice 
peuvent etre redefinies grace a l'heritage de classe. Le tableau ci-dessous 
dresse la liste integrale de ces methodes autogenerees dont on peut sur- 
charger la configuration depuis la classe d'actions du module. 



Tableau 12-1 Liste des actions auto generees par le generateur d'administration 



Norn de la methode 


Description 


executelndexO 


Execute la vue 1 i st 


executeFi lter() 


Met a jour les filtres 


executeNewQ 


Execute Taction de la vue new 
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Tableau 12-1 Liste des actions auto generees par le generateur d'administration (suite) "| 



Nom de la methode 


Description 


executeCreate() 


Cree une nouvelle offre dans la base de donnees 


executeEdi t() 


Execute Taction de la vue edi t 


executeUpdate() 


■ ■ > ■ rr i ii ii ' 

Met a jour une offre dans la base de donnees 


executeDelete() 


Supprime une offre d'emploi 


executeBatchO 


Execute une action sur un lot d'objets 


executeBatchDel ete() 


Execute Taction de suppression par lot _del ete 


processForm() 


-r ■ * i r i a if rr if i 1 

Traite le formulaire d une offre d emploi 


getFilters() 


n i 1 1 ■ i 1 f' 1 ■ i 

Retourne la liste des filtres courants 


setFiltersO 


Definit les filtres courants 


getPager() 


n ■ 1 ' 1 ■ . 1 ■ II !■■ 

Retourne 1 objet de pagination de la vue liste 


getPage() 


Retourne la page courante de pagination 


setPage() 


Definit la page courante de pagination 


buildCriteriaO 


Construit le critere de tri de la liste 


addSortCri teria() 


Ajoute le critere de tri a la liste 


getSortO 


Retourne la colonne de tri courante 


setSort() 


Definit la colonne de tri courant 



II faut savoir que chaque methode generee ne realise qu'un traitement 
bien specifique, ce qui permet de modifier certains comportements sans 
avoir a copier et coller trop de code, ce qui irait a l'encontre de la philo- 
sophic DRY du framework. 



Personnaliser les templates d'un module 
autogenere 

Tous les templates construits par le generateur d'administration ont la 
particularite d'etre facilement personnalisables dans la mesure oil ils con- 
tiennent tous de nombreuses classes CSS et attributs id dans le code 
HTML. Cependant, il arrive parfois que cela ne suffise pas pour aboutir 
au meme resultat que la maquette graphique choisie par le client. 

Au meme titre que pour les classes, tous les templates originaux des modules 
autogeneres sont entierement redefinissables. II est important de rappeler 
qu'un template n'est en fait qu'un simple fichier PHP contenant unique- 
ment du code HTML et PHP. Creer un nouveau template du meme nom 
que l'original dans le repertoire apps/backend/modules/job/templates/ 
(ou job est ici le nom du module concerne) suffit pour qu'il soit utilise. 
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Le tableau suivant decrit l'ensemble des templates necessaires au bon 
fonctionnement des modules batis a partir du generateur de backoffice. 
Tous remplissent une fonction bien precise dans la generation d'une 
page d'administration, ce qui permet, comme pour les classes autogene- 
rees, de pouvoir en surcharger seulement quelques uns pour personna- 
liser le rendu d'un module. 



Tableau 12-2 Liste des templates autogeneres par le generateur d'administration 



no m au Template 


Description 


n <r r Q-f- c n l*i n 

dbbcib . pnp 


Dnnrl qc tgmi ac rlo c+wlo o+ la\/aQrrin+ a iiti hear Hanc o tfltnn ata 
r\cllU leb IcUllleb Uc blylc cL JdvdJLIIUL d UUIIbcl Udllb Ic LclllUldLc 


\\ i ici b . pnp 


RonH la harro latoralo Hoc filtroc 
r\c[lu Id Udllc Idlcldlc Ucb lllllcb 


t i i ici b_T i c i u . pnp 


RonH iin rhamn iinimio Ho la harro Ho filtroc 
r\c[lu Ull LMdllip UN IL|U tr Uc Id Udllc Uc IIILIcb 


_t i dbncb . pnp 


Ronrl loc moccanoc flach rlo fooHharL* 
rVcllU leb IIIcbbdLJcb lldbll Uc IccUUdLK. 


■nr\ r*m n l*i r\ 

to i rn . pnp 


ATTirno lo fnrmiilairo 
MIIILIIc Ic lUIIIIUIdllc 


i o i in dc l i un b . pnp 


Affirho loc artinnc rlii fnrmiilairo 
MIIILIIc leb dLUUIIb UU lUIIIIUIdllc 


_TO 1 m T 1 c i u . p n p 


Affirno iin rhamn imimio Hi i fnrmiilairo 
MIIILIIc Ull LlldlllU UIIILjUc UU lUIIIIUIdllc 


to i rn t iciubcT.pnp 


Affirho iin nrni mo rlo rhamnc rlo momo natiiro rlanc lo fnrmiilairo 
MIIILIIc Ull yrUUpt: Uc Llldllipb Uc lllclllc lldlUIc Udllb Ic lUIIIIUIdllc 


Toim ruuici .pnp 


Affirho lo niorl rlii fnrmiilairo 
MIIILIIc Ic UlcU UU lUIIIIUIdllc 


Torrn ncaUci .pnp 


Affirho I'on-toto rli i fnrmiilairo 
MIIILIIc 1 ell LcLc UU lUIIIIUIdllc 


1 i st . php 


Affirho la hero H'nhio+c 
MIIILIIc Id llbLc U UUJclb 


lib L dC L 1 Ullb . pnp 


Affirho loc ar+mnc Ho la hero 
MIIILIIc leb dLUUIIb Uc Id MbLc 


i \ bT_rjd.Tcn_d.CT i onb . pnp 


Affirno loc ar+innc Ho nt H nhiotc Ho la ic+o 
MIIILIIc leb dLUUIIb Uc IUI U UUJclb Uc Id MbLc 


i \ bT t\ c i uuoo i can . pnp 


Affirho iin rhamn Ho h/no hnnloon Hanc la licto 
MIIILIIc Ull LlldlllU Uc LyUc UUUIccll Udllb Id MbLc 


list" "FnoTpr nhn 


Affirhp Ip nipfi Hp la IKtp 


_list_header.php 


Affiche I'en-tete de la liste 


_1 i st_td_acti ons . php 


Affiche les actions unitaires d'un objet represents par une ligne du tableau 


_1 i st_td_batch_acti ons . php 


Affiche la case a cocher d'un objet 


_1 i st_td_stacked . php 


Affiche le layout stacked d'une ligne 


_1 i st_td_tabul ar . php 


Affiche un champ unique d'une ligne 


_1 i st_th_stacked . php 


Affiche les proprietes d'un enregistrement dans une seule colonne sur toute la ligne 


_1 i st_th_tabul ar . php 


Affiche les proprietes d'un enregistrement dans des colonnes separees du tableau 


_pagi nation. php 


Affiche la pagination de la liste d'objets 


editSuccess . php 


Affiche la vue d'edition d'un objet 


i ndexSuccess . php 


Affiche la vue liste du module 


newSuccess.php 


Affiche la vue de creation d'un nouvel objet 



La configuration finale du module 

Avec seulement deux fichiers de configuration et quelques ajustements 
dans le code PHP generes, l'application Jobeet se dote d'une interface 
d'administration complete en un temps record. Les deux codes suivants 
synthetisent toute la configuration finale des modules presentee pas a 
pas tout au long de ce chapitre. 

Configuration finale du module job 

Configuration finale du module job dans le fichier apps/backend/modules/job/ 
config/generator.yml 

generator : 

class: sfDoctri neGenerator 
param: 

model _cl ass: JobeetJob 
theme: admin 
non_verbose_templates : true 
with_show: false 
singular: 
plural: 

route_prefix: jobeet_job 
wi th_doctri ne_route : 1 

config: 

actions: ~ 
fields: 

is_activated: { label: Activated?, help: Whether the 
user has activated the job, or not } 

is_public: { label: Public? } 
list: 

title: Job Management 

layout: stacked 

display: [company, position, location, url , 

is_activated, email] 

params: | 

%%i s_acti vated%% <smal 1 >%%JobeetCategory%%</smal 1 > 
- %%company%% 
(<em>%%email%%</em>) is looking for a %%=position%% 
(%%location%%) 
max_per_page: 10 

sort: [expires_at, desc] 

batch_actions : 

_delete: 

extend: 
object_actions: 

extend: 

_edit: 

_delete: 
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actions : 

deleteNeverActivated: { label: Delete never activated 

jobs } 

tabl e_method : retri eveBackendJobLi st 
filter: 

display: [category_i d , company, position, description, 
is_activated, is_public, email, expi res_at] 

form: 

class: BackendJobeetJobForm 
di splay: 

Content: [category_i d , type, company, logo, url, 
position, location, description, 
how_to_apply , is_public, email] 

Admin: Lgenerated_token , is_activated, expi res_at] 
edit: 

title: Editing Dob "%%company%% is looking for a 
%%position%%" 
new: 

title: Job Creation 



Configuration finale du module category 

Configuration finale du module category dans le fichier apps/backend/modules/ 
category/config/generator.yml 

generator : 

class: sfDoctri neCenerator 
param: 

model_class: JobeetCategory 
theme: admin 
non_verbose_templ ates : true 
with_show: false 
singular: 
pi ural : 

route_prefix: jobeet_category 
with_doctrine_route: 1 



config: 

actions: ~ 
fields: ~ 
list: 

title: Category Management 
display: [=name, slug] 
batch_actions : {} 
object_actions : {} 
filter: 

class: false 
form: 
actions : 

_delete: ~ 

_1 i st : 

_save: 



edit: 

title: Editing Category "%%name%%" 
new: 

title: New Category 



ASTUCE Configuration YAML vs configuration PHP 



A present, vous savez que lorsque quelque chose est configurable dans un fichier YAML, c'est 
egalement possible avec du code PHP pur. En ce qui concerne le generateur de backoffice, 
toute la configuration PHP se trouve dans le fichier apps/backend/modul es/job/ 
"lib/jobGeneratorConfiguration. class, php. Ce dernier fournit les memes 
options que le fichier YAML mais avec une interface en PHP. Afin d'apprendre et de connaitre 
les noms des methodes de configuration, il suffit de jeter un oeil aux classes de base auto- 
generees (par exemple BaseJobCeneratorConfiguration) dans le fichier de confi- 
guration PHP 

cache/backend/dev/modul es/auto Job/1 i b/ 



En resume... 

En seulement moins d'une heure, le projet Jobeet dispose d'une interface 
complete d'administration des categories et des offres d'emploi deposees 
par les utilisateurs. Mais le plus etonnant, c'est que l'ecriture de toute cette 
interface de gestion n'aura meme pas necessite plus de cinquante lignes de 
code PHP. Ce n'est pas si mal pour autant de fonctionnalites integrees ! 

Le chapitre suivant aborde un point essentiel du projet Jobeet : la securi- 
sation du backoffice d'administration a l'aide d'un identifiant et d'un 
mot de passe. Ce sera egalement l'occasion de parler de la classe Sym- 
fony qui gere l'utilisateur courant. . . 
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chapitre 




1 


Eisijnnfong 










Login Required 

This page is not public. 




How to access this page 

You must proceed to the login page and enter your id and password. 
What's Next 

Q? Proceed to loain 

Back to previous ease 





Authentification et droits 
avec I'objet sfUser 



MOTS-CLES 



Gerer l'authentification d'un utilisateur, lui accorder des droits 
d'acces a certaines ressources, ou bien garder en memoire 
des informations dans la session en cours est monnaie courante 
dans une application web actuelle. 

Le framework Symfony integre nativement tous ces 
mecanismes afin de faciliter la gestion de l'utilisateur qui 
navigue sur l'application. 



► Authentification 

► Droits d'acces 

► ObjetsfUser 



Le chapitre precedent a ete l'occasion de decouvrir tout un lot de nou- 
velles fonctionnalites propres au framework Symfony. Avec seulement 
quelques lignes de code PHP, le generateur d'administration de Sym- 
fony assure au developpeur la creation d'interfaces de gestion en quel- 
ques minutes. 

Les prochaines pages permettent de decouvrir comment Symfony gere la 
persistance des donnees entre les requetes HTTP. En effet, le protocole 
HTTP est dit « sans etat », ce qui signifie que chaque requete effectuee est 
completement independante de celle qui la precede ou de celle qui lui suc- 
cede. Les sites web d'aujourd'hui necessitent un moyen de faire persister 
les donnees entre les requetes afin d'ameliorer 1' experience de l'utilisateur. 

La session d'un utilisateur peut etre identifiee a l'aide d'un « cookie ». 
Dans Symfony, le developpeur n'a nul besoin de manipuler directement 
la session car celle-ci est en fait abstraite grace a l'objet sfUser qui repre- 
sente l'utilisateur final de l'application. 



Culture technique Qu'est-ce qu'un cookie ? 

Malgre tout ce que Ton a pu lui reprocher dans le passe au sujet de la securite, un cookie n'en 
demeure pas moins un simple fichier texte depose temporairement sur le poste de l'utilisateur. 
L'objectif premier du cookie dans une application web est la reconnaissance de l'utilisateur entre 
deux requetes HTTP ainsi que le stockage de breves informations n'excedant pas 4 kilo-octets. 
Un cookie possede au minimum un nom, une valeur et une date d'expiration dans le temps. 
D'autres parametres optionnels supplementaires peuvent lui etre attribues comme son 
domaine de validite ou bien le fait qu'il soit utilise sur une connexion securisee via le proto- 
cole HTTPS. Un cookie est cree par le navigateur du client a la demande du serveur lorsque ce 
dernier lui envoie les en-tetes adequats. A chaque nouvelle requete HTTP, si le navigateur du 
client dispose d'un cookie valable pour le nom de domaine en cours, il transmet le nom et la 
valeur de son cookie au serveur qui pourra ainsi operer des traitements particuliers. 



Decouvrir les fonctionnalites de base de 
l'objet sfUser 

Le chapitre precedent fait quelque peu usage de l'objet sfUser qui garde 
en memoire les messages de feedback a afficher a l'utilisateur apres que 
celui-ci a realise une action. La presente partie explique ce qu'ils sont 
reellement, comment ils fonctionnent et comment les utiliser dans les 
developpements Symfony. 



Comprendre les messages « flash » de feedback 



A quoi servent ces messages dans Symfony ? 

Dans Symfony, un « flash » est un message ephemere stocke dans la ses- 
sion de l'utilisateur et qui est automatiquement supprime a la toute pro- 
chaine requete. Ces messages sont particulierement utiles lorsque Ton a 
besoin d'afficher un message a l'utilisateur apres une redirection. Le gene- 
rateur d'administration a recours a ces messages de feedback des lors 
qu'une offre est sauvegardee, supprimee ou bien prolongee dans le temps. 



Jobeet 



lobs Categories 



EDITING JOB "EXTREME SENSIO IS LOOKING FOR A WEB DESIGNER" 



The item was updated successfully. 
Content 

Category Design 



Type 

Com pany Extreme Sensio 

Company logo 



C Full time © Part time O Freelance 



Q 

EXTREMES 

sensio 



□ remove the current file 



( Browse... ) 



Figure 13-1 

Exemple de message flash 
dans I'administration de 
Jobeet 



Ecrire des messages flash depuis une action 

Les messages flash de feedback sont generalement definis dans les 
methodes des classes d'action apres que l'utilisateur a effectue une opera- 
tion sur 1'application. La mise en memoire d'un message est triviale 
puisqu'il s'agit simplement d'utiliser la methode setFlash() de l'objet 
sfUser courant comme le montre le code ci-dessous. 



Exemple de creation d'un message flash dans le fichier apps/frontend/modules/job/ 
actions/actions.class.php 

public function executeExtend(sfWebRequest Srequest) 
{ 

$request->checkCSRFProtection() ; 
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Remarque Acceder a d'autres objets 
internes de Symfony dans les templates 

D'autres objets internes de Symfony sont toujours 
accessibles dans les templates, sans avoir a les 
leur passer explicitement depuis une action. II 
s'agit par exemple des objets sfRequest, 
sfllser ou bien encore sfResponse qui se 
trouvent respectivement dans les variables 
$sf_request, $sf_user et 

$sf_response. 



$job = $this->getRoute()->getObject() ; 
$thi s->forward404Un1 ess($job->extend()) ; 

$this->getUser()->setF1ash('notice' , sprintf ( ' Your job 
validity has been extend until %s.', date('m/d/Y' , 
strtotime($job->getExpiresAt ())))) ; 

$this->redi rect($thi s->generateUrl ( ' job_show_user ' , $job)) ; 

} 

La methode setFlashO accepte deux arguments. Le premier est l'iden- 
tifiant du message flash tandis que le second est le corps exact du mes- 
sage. II est possible de definir n'importe quel identifiant de message 
flash, mais noti ce et error sont les plus communs car ils sont principale- 
ment utilises par le generateur d'administration. Ils servent respective- 
ment a afficher des messages d'information et des messages d'erreur. 

Lire des messages flash dans un template 

C'est au developpeur qu'incombe la tache d'inclure ou non les messages 
flash dans les templates. Pour ce faire, Symfony integre les deux 
methodes hasFlashO et getF1ash() de l'objet sfUser. Ces dernieres per- 
mettent respectivement de verifier si l'utilisateur possede ou non un 
message flash pour l'identifiant passe en parametre, et de recuperer 
celui-ci en vue de son affichage dans le template. Dans Jobeet par 
exemple, les flashs sont tous affiches par le fichier layout. php. 

Affichage des messages flash dans le fichier apps/frontend/templates/layoutphp 

<?php if ($sf user->hasFlash('notice')) : ?> 
<div c1ass="flash_notice"x?php echo $sf_user 
->getFlash('notice') ?></div> 
<?php endif; ?> 

<?php if ($sfuser->hasFlash( 'error ')) : ?> 
<div c1ass="flash_error"x?php echo $sf user 
->getFl ash ('error') ?></div> 
<?php endif; ?> 

Dans un template, l'objet sfUser est accessible via la variable speciale 
$sf_user. 

Stocker des informations dans la session courante de 
l'utilisateur 

Pour l'instant, les cas d'utilisation de Jobeet ne prevoient aucune con- 
trainte particuliere impliquant le stockage d'informations dans la session 
de l'utilisateur. Pourquoi ne pas ajouter un nouveau besoin fonctionnel 
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permettant de faire usage de la session ? II s'agit en effet de developper 
un mecanisme simple d'historique dans le but de faciliter la navigation 
de l'utilisateur. A chaque fois que ce dernier consulte une offre, celle-ci 
est conservee dans 1'historique, et les trois dernieres offres lues sont reaf- 
fichees dans la barre de menu afin de pouvoir y revenir plus tard. 

Lire et ecrire dans la session de l'utilisateur courant 

Pour repondre a cette problematique, il convient de sauvegarder dans la 
session de l'utilisateur un historique des offres d'emploi lues et d'y ajouter 
l'offre en cours de consultation a son arrivee. Pour ce faire, le framework 
Symfony introduit les methodes getAttributeO et setAttributeO de 
l'objet sfUser qui permettent respectivement de lire et d'ecrire des infor- 
mations dans la session persistante. Le bout de code ci-dessous illustre le 
principe de fonctionnement de la session de l'utilisateur. 

<?php 

public function executeAction(sfWebRequest Srequest) 
{ 

$this->getUser()->setAttribute(' foo' , 'bar');// Set bar in the foo session variable 
$foo = $this->getUserO->getAttribute('foo' , 'baz') ;// Returns bar 

} 

Dans cet exemple, la methode setAttributeO de l'objet sfUser sauve- 
garde la valeur bar dans la variable de session foo. Puis cette valeur est 
recuperee au moyen de la methode getAttributeO a laquelle est passe en 
premier argument le nom de la variable de session. Cette methode accepte 
egalement un second argument facultatif qui correspond a la valeur par 
defaut a renvoyer si la variable de session est vide ou n'existe pas. 



Implementer 1'historique de navigation de l'utilisateur 

L'implementation de 1'historique de navigation de l'utilisateur ne pose 
pas de difficultes particulieres. II s'agit en effet de sauvegarder en session 
persistante un tableau des cles primaires des offres d'emploi deja consul- 
tees. L'algorithme tient en seulement trois lignes de code PHP comme le 
montre le code PHP ci-dessous. 

Implementation de 1'historique de navigation dans la methode executeShow() du 
fichier apps/frontend/modules/job/actions/actions.class.php 

class jobActions extends sfActions 
{ 

public function executeShow(sfWebRequest Srequest) 
{ 

$this->job = $this->getRoute()->get0bjectO ; 
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// fetch jobs already stored in the job history 
$jobs = $this->getUser()->getAttribute(' job history' , 
arrayO) ; 

// add the current job at the beginning of the array 
array unshift($jobs, $this->job->getId()) ; 

// store the new job history back into the session 
$this->getl)ser()->setAttribute(' job history' , $jobs) ; 

} 

// ... 

} 

Bien qu'il soit possible de stacker des objets PHP directement dans une 
session, cette pratique n'en demeure pas moins fortement deconseillee 
dans la mesure ou toutes les variables de session sont serialisees entre 
chaque requete. Lorsqu'une session est recreee sur une nouvelle page, les 
objets quelle contient sont deserialises, c'est-a-dire qu'ils sont recons- 
truits et qu'ils peuvent etre alteres ou bien obsoletes s'ils ont ete modifies 
ou bien supprimes entre-temps. 

Refactoriser le code de l'historique de navigation dans 
le modele 

L'action executeShowO nest pas l'endroit le plus ideal pour accueillir la 
logique de l'historique de navigation. En effet, le code en devient entie- 
rement dependant, ce qui l'empeche d'etre reutilise ailleurs. D'autre part, 
il n'est pas factorise et complexifie ainsi inutilement Taction 
executeShowO. 

Implementer l'historique de navigation dans la classe myUser 

D'apres ce dernier postulat, on en deduit rapidement le besoin de 
deplacer le code vers la couche du modele afin de respecter la separation 
entre les differentes logiques. Le meilleur endroit pour recevoir l'imple- 
mentation de l'historique de navigation est naturellement la classe 
myUser qui surcharge les specificites de la classe de base sfUser avec des 
comportements propres a l'application courante. 

Implementation de la methode addJobToHistoryO dans la classe myUser du fichier 
apps/frontend/lib/myUser.class.php 

: class myUser extends sf Basi cSecuri tyUser 
{ 

public function addJobToHi story (JobeetJob $job) 
{ 

$ids = $this->getAttribute(' job history' , arrayO); 



if (! in array($job->getId() , $ids)) 
{ 

array unshift($ids, $job->getId()) ; 

$this->setAttribute(' job history' , array si ice($ids, 0, 

3)); 

} 

} 

} 

Le remaniement du code prend desormais en compte toutes les con- 
traintes de l'historique de navigation. L'instruction in_array($job- 
>getld() , $ids) s'assure que l'offre d'emploi n'existe pas deux fois dans 
l'historique de navigation tandis que l'instruction array_sl i ce ($i ds , 0 , 
3) se contente de recuperer uniquement les cles primaires des trois der- 
nieres annonces consultees par l'utilisateur en vue de reafficher un lien 
vers chacune d'elle dans la page courante. 

Simplifier I'action executeShow() de la couche contrdleur 

L'etape suivante consiste a mettre a jour Taction executeShowO prece- 
dente afin de la simplifier en lui implementant la methode 
addJobToHistoryC). 

Remaniement de la methode executeShowO dans le fichier apps/frontend/modules/ 
job/actions/actions.class.php 

class jobActions extends sfActions 
{ 

public function executeShow(sfWebRequest Srequest) 
{ 

$this->job = $this->getRoute()->get0bjectO ; 
$this->getUser()->addJobToHi story ($this-> job) ; 

} 

// ... 

} 

Grace au remaniement du code, Faction ne comporte plus que deux 
lignes de code PHP alors qu'il en fallait quatre precedemment. La der- 
niere etape consiste enfin a recuperer les offres d'emploi de l'historique 
puis afficher leur titre respectif sur la page en cours. 

Afficher l'historique des offres d'emploi consultees 

A present, il ne reste plus qua ajouter le programme PHP qui genere 
dans la vue le code HTML de l'historique des trois dernieres annonces. 
Limplementation de ce script est a ajouter avant la variable $sf_content 
du fichier 1 ayout . php comme l'illustre le code ci-dessous. 



Generation de I'historique des offres dans le fichier apps/frontend/templates/ 
layout, php 

<div id="job history"> 
Recent viewed jobs: 
<ul> 

<?php foreach ($sf user->getJobHi story () as $job): ?> 
<li> 

<?php echo link to($job->getPosition() . ' - ' 

. $job->getCompany() , 'job show user' , $job) ?> 

</li> 

<?php endforeach; ?> 
</ul> 
</div> 

<div class="content"> 

<?php echo $sf_content ?> 
</di v> 

Ce template fait appel a la methode getDobHi story () de l'objet sfUser. 
Cette methode a pour role de recuperer les trois derniers objets JobeetJob 
de la base de donnees a partir des identifiants des offres sauvegardes dans 
la session courante de l'utilisateur. Le fonctionnement de la methode 
get JobHi storyO est trivial puisqu'il s'agit de faire appel a I'historique des 
offres dans la session, puis de retourner l'objet Doct ri ne_Col lection resul- 
tant de la requete SQL executee par Doctrine. 

Implementation de la methode getJobHistoryO dans la classe myUser du fichier 
apps/frontend/lib/myUser.class.php 

class myUser extends sf Basi cSecuri tyUser 
{ 

public function getJobHistoryO 
{ 

$ids = $this->getAttribute( ' job history' , arrayO); 

if (!empty($ids)) 
{ 

return Doctrine: :getTable(' JobeetJob') 
->createQuery( ' a' ) 
->whereln('a. id' , $ids) 
->execute() ; 

} 

el se 
{ 

return arrayO; 

} 

} 



// 

} 



La capture d'ecran ci-dessous presente le resultat final obtenu apres que 
l'historique de navigation a ete completement implemente. 



Jobeet 




» 



Enter some keywords (city, country, position, ...) 



Recent viewed jobs: Web Designer - Extreme Sensio Web Developer - Company 100 Web Developed - Sers o Laps 



DESIGN 



Paris, France 



Web Designer 



Extreme Sensio 



Figure 13-2 

Exemple de l'historique 
de navigation reposant 
sur les informations 
sauvegardees en session 



Implementer un moyen de reinitialiser l'historique des offres 
consultees 

Tous les attributs de l'utilisateur sont geres par une instance de la classe 
sf Parameter-Holder. Les methodes getAttri bute() et setAttri bute() 
sont deux methodes « proxy » (raccourcies) pour getParameterHolder- 
>get() et getParameterHolder()->set(). 

Lobjet sfParameterHolder contient egalement une methode remove() 
qui permet de supprimer un attribut de la session de l'utilisateur. Cette 
methode n'est associee a aucune methode raccourcie dans la classe 
sfUser, c'est pourquoi le code ci-dessous fait directement appel a l'objet 
sfParameterHolder pour supprimer l'attribut jobjii story, et ainsi vider 
l'historique des offres consultees. 

Implementation de la methode resetJobHistory dans la classe myUser du fichier 
apps/frontend/lib/myUser.class.php 

class myUser extends sfBasicSecurityUser 
{ 

public function reset DobHi story () 
{ 

$thi s->getAttr i buteHol der () ->remove( ' job hi story ' ) ; 

} 

// ... 



La classe sfParameterHolder est egalement utilisee par l'objet sf Request 
pour sauvegarder ses differents parametres. 
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Les sections suivantes de ce chapitre abordent de nouvelles notions cles 
du framework Symfony. II s'agit en effet de decouvrir les mecanismes 
internes de securisation des applications et de controle de droits d'acces 
de l'utilisateur. Un systeme d'authentification avec nom d'utilisateur et 
mot de passe pour l'application backend de Jobeet est developpe en guise 
d'exemple pratique. 

Comprendre les mecanismes de 
securisation des applications 

Cette partie s'interesse aux principes d'authentification et de controle de 
droits d'acces sur une application. L'authentification consiste a s'assurer 
que l'utilisateur courant est bien authentifie sur l'application ; c'est par 
exemple le cas lorsqu'il remplit un formulaire avec son couple d'identifiant 
et mot de passe valides. Le controle d'acces, quant a lui, verifie que l'utili- 
sateur dispose des autorisations necessaires pour acceder a tout ou partie 
d'une application (par exemple, lorsqu'il s'agit de lui empecher la suppres- 
sion d'un objet s'il ne dispose pas d'un statut de super administrateur). 

Activer l'authentification de l'utilisateur sur une application 
Decouvrir le fichier de configuration security.yml 

Comme avec la plupart des fonctionnalites de Symfony, la securite d'une 
application est geree au travers du fichier YAJVIL security.yml. Pour 
l'instant, ce fichier se trouve par defaut dans le repertoire apps/backend/ 
conf i g/ du projet et desactive toute securite de l'application comme le 
montre son contenu : 

Contenu du fichier apps/backend/config/security.yml 

default: 

is_secure: off 

En fixant la constante de configuration is_secure a la valeur on, toute 
l'application backend forcera l'utilisateur a etre authentifie pour aller 
plus loin. La capture d'ecran ci-dessous illustre la page affichee par 
defaut a l'utilisateur si ce dernier n'est pas authentifie. 



BJsgmfong 



ipl Login Required 

This page is not public. 



How to access this page 

You must proceed to the login page and enter your id and password. 
What's Next 

Proceed to login 
C-? Back to previous page 



Figure 13-3 

Page de login par defaut de Symfony 
pour un utilisateur non identifie 



Dans un fichier de configuration YAML, une valeur booleenne peut etre 
exprimee a l'aide des chaines de caracteres on, off, true ou bien false. 
Comment se fait-il que l'utilisateur se voit redirige vers cette page qui 
n'apparait nulle part dans le projet ? La reponse se trouve tout naturellement 
dans les logs que Symfony genere en environnement de developpement. 

Analyse des logs generes par Symfony 

L'analyse des logs dans la barre de debogage de Symfony indique que la 
methode executel_ogin() de la classe defaultActions est appelee pour 
chaque page a laquelle l'utilisateur tente d'acceder. 



2ft ^ FiltorChain Executirg filar 'sfValtaatiofiExecutionFilter* 

29 dofaultActjors Call *GefaLltActiors >execi.teLogtrO* 

30 £J pHPviow Rerder *sf_symfony_lib_OH , /cortroller/cefaulttemplates/logipSuccess-php* 



Figure 13-4 

Extrait des logs lorsque l'utilisateur tente 
d'acceder a une page securisee 



Le module default n'existe pas reellement dans un projet Symfony 
puisqu'il s'agit d'un module livre entierement avec le framework. Bien 
evidemment, l'appel a la methode executeLogin() du module default 
est entierement redefinissable afin de pouvoir rediriger automatique- 
ment l'utilisateur vers une page personnalisee. 

Personnaliser la page de login par defaut 

Lorsqu'un utilisateur essaie d'acceder a une action securisee, Symfony 
delegue automatiquement la requete a Taction login du module default. 
Ces deux informations ne sont pas choisies au hasard par le framework 
puisqu'elles figurent dans le fichier de configuration settings. yml de 
l'application. Ainsi, il est possible de redefinir soi-meme Taction personna- 
lisee a invoquer lorsqu'un utilisateur souhaite acceder a une page securisee. 
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Redefinition de Taction login dans le fichier apps/backend/config/settings.yml 



all : 

.actions: 
login_module: default 
login_action: login 

Pour des raisons techniques evidentes, il est impossible de securiser la 
page de login afin d'eviter une recursivite infinie. Au chapitre 4, il a ete 
demontre qu'une meme configuration s'etalonne a plusieurs endroits 
dans le projet. II en va de meme pour le fichier security.yml. En effet, 
pour securiser ou retirer la securite d'une action ou de tout un module de 
l'application, il suffit d'ajouter un fichier security.yml dans le repertoire 
conf i g/ du module concerne. 

index: 

is_secure: off 

all : 

is_secure: on 

Authentifier et tester le statut de I'utilisateur 

Par defaut, la classe myUser derive directement de la classe 
sfBasicSecurityUser qui etend elle-meme la classe sfUser. 
sfBasicSecurityUser integre des methodes additionnelles pour gerer 
1'authentification et les droits d'acces de I'utilisateur courant. Lauthenti- 
fication de I'utilisateur se manipule avec deux methodes seulement : 
isAuthenticatedO et setAuthenti cated(). La premiere se contente de 
retourner si oui ou non I'utilisateur est deja authentifie, alors que la 
seconde permet de i'authentifier (ou de le deconnecter). Le bout de code 
illustre leur fonctionnement dans le cadre d'une action. 

i f ( ! $thi s->getUser () ->i sAuthenti cated () ) 
{ 

$this->getUser()->setAuthenti cated (true) ; 

} 

A present, il est temps de s'interesser au mecanisme natif de controle de 
droits d'acces. La section suivante explique comment restreindre tout ou 
partie des fonctionnalites d'une application a I'utilisateur en lui affectant 
un certain nombre de droits. 

Restreindre les actions d'une application a I'utilisateur 

Dans la plupart des projets complexes, les developpeurs sont confrontes 
a la notion de politique de droits d'acces aux informations. C'est d'autant 



plus vrai dans le cas d'une interface de gestion ou bien dans un Intranet 
pour lequel il peut exister plusieurs profils d'utilisateurs : administrateur, 
publicateur, moderateur, tresorier... Tous ne possedent pas les memes 
autorisations et ne peuvent dans ce cas avoir acces a certaines parties de 
l'application lorsqu'ils sont connectes. Heureusement, Symfony integre 
parfaitement un systeme de controle de droits d'acces simple et rapide a 
mettre en ceuvre. 

Activer le controle des droits d'acces sur ('application 

Lorsqu'un utilisateur est authentifie sur l'application, il ne doit pas for- 
cement avoir acces a toutes les fonctionnalites de cette derniere. Cer- 
taines zones peuvent done lui etre restreintes en etablissant une politique 
de droits d'acces. L'usager doit alors posseder les droits necessaires et 
suffisants pour atteindre les pages qu'il desire. Dans Symfony, les droits 
de l'utilisateur sont nommes credentials et se declarent a plusieurs 
niveaux. Le code ci-dessous du fichier security.yml de l'application 
desactive l'authentification mais contraint neanmoins l'utilisateur a pos- 
seder les droits d'administrateur pour aller plus loin. 

default: 

is_secure: off 
credentials: admin 

Le systeme de controle de droits d'acces de Symfony est particuliere- 
ment simple et puissant. Un droit peut representer n'importe quelle 
chose pour decrire le modele de securite de l'application comme les 
groupes ou les permissions. 

Etablir des regies de droits d'acces complexes 

La section credentials du fichier security .yml supporte les operations 
booleennes pour decrire les contraintes de droits d'acces complexes. Par 
exemple, si un utilisateur est contraint d'avoir les droits A et B, il suffit 
d'encadrer ces deux derniers avec des crochets. 

index: 

credentials: [A, B] 

En revanche, si un utilisateur doit avoir les droits A ou B, il faut alors 
encadrer ces derniers par une double paire de crochets comme ci-dessous. 

i ndex : 

credentials: [[A, B] ] 



Au final, il est possible de mixer a volonte les regies booleennes jusqu'a 
trouver celle qui correspond a la politique de droits d'acces que Ton sou- 
haite mettre en application. 



Gerer les droits d'acces via I'objet sfBasicSecurityUser 

Toute la politique de droits d'acces peut egalement etre geree directe- 
ment grace a I'objet sfBasicSecurityUser qui fournit un ensemble de 
methodes capables d'aj outer ou de retirer des droits a l'utilisateur, mais 
qui permet egalement de tester si ce dernier en possede certains, comme 
le montrent les exemples ci-dessous. 

// Add one or more credentials 
$user->addCredential ('foo') ; 
I $user->addCredentials('foo' , 'bar'); 

// Check if the user has a credential 

echo $user->hasCredential ('foo') ; => true 

// Check if the user has both credentials 

echo $user->hasCredential (array('foo' , 'bar')); => true 

// Check if the user has one of the credentials 

echo $user->hasCredenti al (array (' foo ' , 'bar'), false); => 

true 

// Remove a credential 
; $user->removeCredential ('foo') ; 
echo $user->hasCredential ('foo') ; => false 

// Remove all credentials (useful in the logout process) 
$user->clearCredentials() ; 

echo $user->hasCredential ('bar') ; => false 

Le tableau ci-dessous resume et detaille plus exactement chacune de ces 
methodes. 



Tableau 13-1 Liste des methodes de I'objet sfBasicSecurityUser 







addCredential ('foo') 


Affecte un droit a l'utilisateur 


addCredentials('foo' , 'bar') 


Affecte un ou plusieurs droits a l'utilisateur 


hasCredenti al ( ' foo ' ) 


Indique si oui ou non l'utilisateur possede le droit foo 


hasCredenti al (array( ' foo ' , ' bar ' )) 


Indique si oui ou non l'utilisateur possede les droits foo et bar 


hasCredenti al (arrayC foo' , 'bar'), false) 


Indique si oui ou non l'utilisateur possede I'un des deux droits 


removeCredenti al ( ' foo ' ) 


Retire le droit foo a l'utilisateur 


clearCredentials() 


Retire tous les droits de l'utilisateur 
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Pour l'application Jobeet, il n'est pas necessaire de gerer les droits d'acces 
dans la mesure ou celle-ci n'accueille qu'un seul type de profils : le role 
administrateur. 

Mise en place de la securite de 
l'application backend de Jobeet 

Tous les concepts presentes dans la section precedente sont plutot theori- 
ques et n'ont pas encore ete veritablement mis en application. II est temps 
de retourner a l'application backend et de lui ajouter la page d'identifica- 
tion qui lui manque pour le moment. L'objectif n'est pas d'ecrire ce type de 
fonctionnalite ex nihilo (from scratch disent les puristes anglicistes), et heu- 
reusement le framework Symfony dispose de tout le necessaire pour 
mettre cela en ceuvre en quelques minutes. II s'agit en effet de recourir a 
l'installation du plugin sfDoctrineGuardPlugin qui integre entre autres les 
mecanismes d'identification et de reconnaissance de l'utilisateur. 

Installation du plug-in sfDoctrineGuardPlugin 

L'une des incroyables forces du framework Symfony reside dans son riche 
ecosysteme de plugins. L'un des prochains chapitres de cet ouvrage 
explique en quoi il est tres facile de creer des plugins et en quoi ces derniers 
sont des outils puissants et pratiques. En effet, un plugin est capable de 
contenir aussi bien des modules que de la configuration, des classes PHP, 
des fichiers XML ou encore des ressources web... Pour le developpement 
de l'application Jobeet, c'est le plugin sf Doctri neGuardPl ugi n qui sera ins- 
talls pour garantir le besoin de securisation de l'interface d'administration. 

L'installation d'un plugin dans le projet est simple puisqu'il suffit d'exe- 
cuter une commande depuis l'interface en ligne de commande Symfony 
comme le montre le code suivant. 

J $ php symfony pi ugi n : i nstall sfDoctrineGuardPlugin 

La commande plugin:install telecharge et installe un plugin a partir 
de son nom. Tous les plugins du projet sont stockes sous le repertoire 
plugins/ et chacun d'eux possede son propre repertoire nomme avec le 
nom du plugin. Bien quelle soit pratique et souple a utiliser, la tache 
pi ugi n : i nstal 1 requiert l'installation de PEAR sur le serveur pour fonc- 
tionner correctement ! 



Lorsque Ton installe un plugin a partir de la tache pi ugi n : i nstal 1 , Sym- 
fony telecharge la toute derniere version stable de ce dernier. Pour installer 
une version specifique d'un plugin, il suffit de lui passer l'option facultative 
— release accompagnee du numero de la version desiree. La page dediee 
du plugin sur le site officiel du framework Symfony liste toutes les versions 
disponibles du plugin pour chaque version du framework. 

Dans la mesure oil un plugin est copie en integralite dans son propre 
repertoire, il est egalement possible de telecharger son archive depuis le 
site officiel de Symfony, puis de la decompresser dans le repertoire 
plugins/ du projet. Enfin, une derniere methode alternative d'installa- 
tion consiste a creer un lien externe vers le depot Subversion du plugin a 
l'aide d'un client Subversion et de la propriete svn: externals sur le 
repertoire plugins/. 

Enfin, il ne faut pas oublier d'activer le plugin apres l'avoir installe si Ton 
n'utilise pas la methode enableAllPluginsExceptO de la classe config/ 
Proj ectConf i gu rati on . cl ass . php. 

Mise en place des securites de Implication backend 
Generer les classes de modele et les tables SQL 

Chaque plugin possede son propre fichier README qui explique comment 
l'installer et le configurer pour le projet. Les lignes qui suivent decrivent 
pas a pas la configuration du plugin sfDoctrineGuardPlugin en com- 
mencant par la generation du modele et des nouvelles tables SQL. En 
effet, ce plugin fournit plusieurs classes de modele pour gerer les utilisa- 
teurs, les groupes et les permissions sauvegardes en base de donnees. 

$ php symfony doctrine:build-all-reload 

La tache doctrine:build-all-reload supprime toutes les tables exis- 
tantes de la base de donnees avant de les recreer une par une. Afin 
d'eviter cela, il est possible de generer le modele, les formulaires et les fil- 
tres, et enfin creer les nouvelles tables en executant le script SQL du 
plugin genere dans le repertoire data/sql/. 

Implementer de nouvelles methodes a I'objet User via la classe 
sfGuardSecurityUser 

Lexecution de la tache doctrine: build-all -reload a genere de nou- 
velles classes de modele pour le plugin sfDoctrineGuardPlugin, c'est 
pourquoi le cache du projet doit etre vide pour les prendre en compte. 

$ php symfony cc 



Dans la mesure ou sfDoctrineGuardPlugin ajoute plusieurs nouvelles 
methodes a la classe de l'utilisateur, il est necessaire de changer la classe 
parente de la classe myUser par sfGuardSecurityUser comme le montre le 
code ci-dessous. 

Redefinition de la classe de base de myUser dans le fichier apps/backend/lib/ 
myUser.class.php 

class myUser extends sfGuardSecurityUser 

{ 

// ... 

} 

Activer le module sfGuardAuth et changer Taction de login par 
defaut 

Le plugin sfDoctrineGuardPlugin fournit egalement une action signin a 
l'interieur du module sfGuardAuth afin de gerer l'authentification des 
utilisateurs. II faut done indiquer a Symfony que e'est vers cette action 
que les utilisateurs non authentifies doivent etre amenes lorsqu'ils 
essaient d'acceder a une page securisee. Pour ce faire, il suffit d'editer le 
fichier de configuration settings. yml de 1'application backend. 

Definition du module et de Taction par defaut pour la page de login dans le fichier 
apps/backend/config/settings.yml 

all : 

. setti ngs : 

enabled_modules: [default, sfGuardAuth] 

# ... 

.actions: 
1 ogi n_modul e : sfGuardAuth 
login action: signin 

# ... 

Dans la mesure ou tous les plugins sont partages pour toutes les applica- 
tions du projet, il est necessaire de n'activer que les modules a utiliser dans 
1'application en les ajoutant explicitement au parametre de configuration 
enabled_modules comme e'est le cas ici pour le module sfGuardAuth. La 
figure ci-dessous illustre la page de login qui est affichee a l'utilisateur 
lorsque ce dernier n'est pas authentifie sur 1'application. 



Figure 13-5 

Page d'identification 
a I'application backend 



Jobcet 



lobs Categories 



Username 
Password 
Remember □ 



Creer un utilisateur administrateur 

La derniere etape consiste a enregistrer dans la base de donnees un 
compte utilisateur autorise a s'authentifier sur l'interface de gestion de 
Jobeet. II serait bien sur possible de realiser cette operation manuelle- 
ment directement dans la base de donnees ou bien a partir d'un fichier 
de donnees initiales mais le plugin fournit des taches Symfony pour faci- 
liter ce genre de procedures. 

$ php symfony guard : create-user fabien SecretPass 
$ php symfony guard : promote fabien 

La tache guard : create-user permet de creer un nouveau compte utilisa- 
teur dans la base de donnees en lui specifiant le nom d'utilisateur en pre- 
mier argument et le mot de passe associe en second. De son cote, la 
tache guard: promote promeut le compte utilisateur passe en argument 
comme super administrateur. 

sfDoctrineGuardPlugin inclut d'autres taches pour gerer les utilisateurs, 
les groupes et les permissions depuis la ligne de commande. Par 
exemple, i'utilisation de la tache 1 i st affiche la liste des commandes dis- 
ponibles sous l'espace de nom guard. 



j $ php symfony list guard 



Cacher le menu de navigation lorsque I'utilisateur n'est pas 
authentifie 

II reste encore un petit detail a regler. En effet, les liens du menu 
d'administration de l'interface backend continuent d'etre affiches meme 
quand I'utilisateur n'est pas authentifie. Ce dernier ne devrait done pas 
etre en mesure de voir ce menu. Pour le masquer, il suffit seulement de 
tester dans le template si I'utilisateur est authentifie ou non grace a la 
methode isAuthenticatedQ vue precedemment. 
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Masquer le menu de navigation a I'utilisateur non identifie dans le fichier apps/ 
backend/templates/layout.php 

<?php if ($sf user->isAuthenticated()) : ?> 

<div id="menu"> 
<ul> 

<lix?php echo 1 i nk_to( ' Jobs ' , '@jobeet_job') ?x/li> 
<lix?php echo 1 i nk_to( ' Categori es ' , '@jobeet_category') ?></l 
<lix?php echo link to(' Logout ' , '@sf guard signout') ?></li> 
</ul> 
</di v> 
<?php endif; ?> 

Un lien de deconnexion a egalement ete ajoute pour permettre a I'utilisa- 
teur connecte de fermer proprement sa session sur l'interface d'adminis- 
tration. Ce lien utilise la route sf_guard_signout declaree dans le plugin 
sfDoctri neGuardPl ugi n. La tache app: routes permet de lister 
I'ensemble des routes definies pour l'application courante. 

Ajouter un nouveau module de gestion des utilisateurs 

La fin de ce chapitre est toute proche mais il est encore temps d'ajouter 
un module complet de gestion des utilisateurs pour parfaire l'application. 
Cette operation ne demande que quelques secondes puisque 
sfDoctri neGuardPl ugi n detient ce precieux module. De la meme 
maniere que pour le module sfGuardAuth, le plugin sfGuardUser doit 
etre reference aupres de la liste des modules actives dans le fichier de 
configuration setti ngs . yml . 

Ajout du module sfGuardUser dans le fichier apps/backend/config/settings.yml 

all : 

. setti ngs : 

enabled_modules: [default, sfGuardAuth, sfGuardUser] 

Le module sfGuardUser a ete genere a partir du generateur d'adminis- 
tration etudie au chapitre precedent. De ce fait, il est entierement para- 
metrable et personnalisable grace au fichier de configuration 
generator. yml se trouvant dans le repertoire config/ du module. 

II ne reste finalement plus qua installer un lien dans le menu de naviga- 
tion afin de permettre a l'administrateur d'acceder a ce nouveau module 
pour gerer tous les comptes utilisateurs de l'application. 

<?php if ($sf_user->isAuthenticated()) : ?> 
<div id="menu"> 
<ul> 

<lix?php echo 1 i nk_to( ' Jobs ' , '@jobeet_job ' ) ?></li> 
<lix?php echo link_to('Categories' , '@jobeet_category ' ) ?> 
</li> 



<1ix?php echo 1 ink_to(' Users' , '@sf guard_user ') ?></li> 
<1ix?php echo 1 ink_to(' Logout ' , '@sf_guard_signout') ?></li> 
</ul> 
</di v> 
<?php endif; ?> 



Figure 13-6 

Rendu final de la page 
d'accueil du module 
sfGuardUser 



Jobeet 



lobs Cateaories 


Users Loaout 
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□ Username 
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Actions 
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□ is empty 



La capture d'ecran ci-dessus illustre le rendu final du menu de naviga- 
tion et du gestionnaire d'utilisateurs qui ont ete ajoutes a l'application en 
quelques minutes seulement. 



Implementer de nouveaux tests 
fonctionnels pour l'application frontend 

Ce chapitre n est pas encore termine puisqu'il reste a parler rapidement 
des tests fonctionnels propres a l'utilisateur. Comme le navigateur de 
Symfony est capable de simuler les cookies, il est tres facile de tester les 
comportements de l'usager a l'aide du testeur natif sfTesterUser. II est 
temps de mettre a jour les tests fonctionnels de l'application frontend 
pour prendre en compte les fonctionnalites additionnelles du menu 
implementees dans ce chapitre. Pour ce faire, il suffit d'ajouter le code 
suivant a la fin du fichier de tests fonctionnels jobActionsTests . php. 

Tests fonctionnels de I'historique de navigation a ajouter a la fin du fichier 
test/ functional/ f rontend/jobActionsTest. php 

$browser-> 

info('4 - User job history')-> 

1oadData()-> 
restart()-> 

info(' 4.1 - When the user access a job, it is added to its 
hi story ')-> 
getC7')-> 
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click('Web Developer', arrayO, arrayCposition' => l))-> 

get('/')-> 

wi th( ' user ' ) ->begi n() -> 

isAttributeC job history' , array($browser-> 

getMostRecentProgrammingJob()->getId ()))-> 

end()-> 

info(' 4.2 - A job is not added twice in the history')-> 
click('Web Developer', arrayO, arrayCposition' => l))-> 
get('/')-> 

wi th( ' user ' ) ->begi n() -> 

isAttributeC job history' . array($browser-> 

getMostRecentProgramming3ob()->getId()))-> 

end() 

> 

Afin de faciliter les tests, il est necessaire de forcer le rechargement des 
donnees initiales de test et de reinitialiser le navigateur afin de demarrer 
avec une nouvelle session vierge. Les tests ci-dessus font appel a la 
methode isAttributeC) du testeur sfTesterUser qui permet de verifier 
la presence et la valeur d'une donnee de session de l'utilisateur. 

Le testeur sfTesterUser fournit egalement les methodes 
isAuthenticatedO et hasCredential 0 qui controlent rauthentification 
et les autorisations de l'utilisateur courant. 



En resume... 

Les classes internes de Symfony dediees a l'utilisateur constituent une 
bonne maniere de s'abstraire de la gestion du mecanisme des sessions de 
PHP. Couplees a l'excellent systeme de gestion des plugins ainsi qu'au 
plugin sfDoctri neGuardPl ugi n, elles sont capables de securiser une 
interface d'administration en quelques minutes ! Au final, 1' application 
Jobeet dispose d'une interface de gestion propre et complete qui permet 
aux administrateurs de gerer des utilisateurs grace aux modules livres par 
le plugin. 

Comme Jobeet est une application Web 2.0 digne de ce nom, elle ne 
peut echapper aux traditionnels flux RSS et Atom qui seront developpes 
avec autant de facilite au cours du prochain chapitre... 



chapitre 




J S'abonner a ce flux en utilisant | |jNptuihp^ 

□ Toujours utiliser Netvibes pour s'abonner aux flux, 

S'abonner maintenant | 



Jobeet 



Web Designer (Paris, France) 

wudi lif. .svril ;0CI9 04:23 



EXTREME 

sensio 

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do 
eiusmod ternpor incididunt ut labore et dolore magna aliqua. Ut 
enim ad minim veniam, quis nostrud exercitation ullamco laboris 
nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor 
in reprehenderit In. 

Voluptate velit esse cillum dotare eu fugiat nulla pariatur, 
Excepteur sint occaecat cupidatat non proident, sunt in culpa 
qui officia deserunt mollit anim id est laborum. 

How to apply? 

Send your resume to fabien.potencier [at] sensio.com 

Web Developer (Paris. France) 

jeudi 16awil2009 04:23 

Lorem ipsum dolor sit amet, consectetut adipisicing elit. 
How to apply? 

Send your resume to lorem. ipsum [at] company_119.sit 

Web Developer (Paris. France) 

jeudi 16 avril 2009 04:23 

Lorem psum dobr sit amet, consectetur adptstting eft, 
How to apply? 

Send your resume to lorem. ipsum [at] company_120.sit 
Web Developer (Paris, Trance) 



Les flux de syndication ATOM 



Toutes les applications web modernes mettent a disposition 

leurs contenus sous forme de flux afin de permettre 

aux internautes de suivre les dernieres informations publiees 

dans leur navigateur ou leur agregateur favoris. L'application 

Jobeet ne deroge pas a cette regie, et, grace au framework 

Symfony, sera pourvue d'un systeme de flux de syndication 

ATOM. 



MOTS-CLES : 

► Formats XML, HTML et ATOM 

► Routage 

► Templates 



La fraicheur et le renouvellement de l'information sont des points majeurs 
qui contribuent a la reussite d'une application web grand public. En effet, 
un site Internet dont le contenu nest pas mis a jour regulierement risque 
de perdre une part non negligeable de son audience, cette derniere ayant le 
besoin permanent d'etre nourrie d'informations nouvelles. 

Or, comment est-il possible d'informer un internaute non connecte au 
site que le contenu de ce dernier a ete mis a jour ? Par exemple, en ce qui 
concerne l'application developpee tout au long de cet ouvrage, il s'agit de 
trouver un moyen de notifier a l'internaute la presence de nouvelles 
offres d'emploi publiees, sans que celui-ci n'ait a se rendre de lui-meme 
sur le site. La reponse a cette problematique se trouve dans les flux de 
syndication (feeds en anglais) RSS et ATOM. En effet, les formats RSS 
et ATOM sont deux standards reposant sur la norme XML, et peuvent 
etre lus par tous les navigateurs web modernes ou par des agregateurs de 
contenus tels que Netvibes, Google Reader, delicious.com... Leur stan- 
dardisation ainsi que leur extreme simplicite servent egalement a 
echanger, voire a publier, de l'information entre les differentes applica- 
tions web ou terminaux (telephones mobiles par exemple). 

Lobjectif de ce quatorzieme chapitre est d'implementer petit a petit des 
flux de syndication ATOM des offres d'emploi afin que l'utilisateur 
puisse etre tenu informe des nouveautes publiees. 

Decouvrir le support natif des formats 
de sortie 

Definir le format de sortie d'une page 

Le framework Symfony dispose d'un support natif des formats de sortie et 
des types de fichiers mimes (mime-types en anglais), ce qui signifie que le 
meme Modele et Controleur peuvent avoir differents templates en fonc- 
tion du format demande. Le format par defaut est bien evidemment le 
HTML mais Symfony supporte un certain nombre de formats de sortie 
supplementaires comme txt, js, ess, json, xml, rdf ou bien encore atom. 

La methode setRequestFormatO de l'objet sfRequest permet de definir 
le format de sortie d'une page. 

$request->setRequestFormat('xm1 ') ; 



< 

Gerer les formats de sortie au niveau du routage f 

C 

Bien qu'il soit possible de definir manuellement le format de sortie d'une j* 1 

action dans Symfony, ce dernier se trouve embarque la plupart du temps * 

dans FURL. De ce fait, Symfony est capable de determiner lui-meme le » 

format de sortie a retourner d'apres la valeur de la variable sf_format de ^ 

la route correspondante. Par exemple, pour la liste des offres d'emploi, rt 
l'url est la suivante : 

http://jobeet.localhost/frontend_dev.php/job 

Cette meme URL est equivalente a la suivante : 

http://jobeet.localhost/frontend_dev.php/job.html 

Ces deux URLs sont effectivement identiques car les routes generees par 
la classe sfDoctrineRouteCol lection possedent la variable sf_format en 
guise d'extension, et parce que le HTML est le format privilegie. Pour 
s'en convaincre, il suffit d'executer la commande app : routes afin 
d'obtenir un resultat similaire a la capture ci-dessous. 



Figure 14-1 

Liste des routes parametrees pour I'application frontend 



~/work/jobeet $ ./symfony app: routes frontend 


» app 


Current 


routes for application "frontend" 


Mane 


Method 


Pattern 


category 


ANY 


/category/: slug 


job 


GET 


/job. :sf .format 


job.new 


GET 


/job/new. :sf .format 


job_create 


POST 


/job. :sf_format 


job.edit 


GET 


/ job/: token/edit. :sf .format 


job.update 


PUT 


/ job/: token. :sf .format 


job.delete 


DELETE 


/job/ : token . : sf .format 


job.sho* 


GET 


/job/:token. :sf_format 


job_publish 


PUT 


/job/ : token/publ i sh . : sf .format 


job_extend 


PUT 


/ job/: token/extend. :sf .format 


job_shoK_user GET 


/job/ : company.slug/ : location.slug/ : id/ : position_slug 


homepage 


ANY 


/ 



Vjobeet S I 



Presentation generate du format ATOM 

Un fichier de syndication ATOM est en realite un document au format 
XML qui s'appuie sur une structure bien definie, localisee dans sa decla- 
ration de type de document : la DTD {Document Type Declaration en 
anglais). Lensemble des specificites du format ATOM depasse large- 
ment le cadre de cet ouvrage ; il est neanmoins necessaire de connaitre 
les fondamentaux pour etre capable de realiser un flux minimal valide. 
La principale chose a retenir a propos du format ATOM concerne sa 
structure. En effet, un flux ATOM est compose de deux parties 
distinctes : les informations generales du flux et les entrees. 
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Les informations globales du flux 

Les informations generates sont situees tout de suite sous 1' element 
racine <feed> du flux. Les balises presentes sous cet element apportent 
des donnees globales comme le titre du flux, sa description, son lien, sa 
ou ses categories, sa date de derniere mise a jour, son logo... Certaines 
d'entre elles sont obligatoires et doivent done figurer imperativement 
dans le flux afin que celui-ci soit considere comme valide. 

Les entrees du flux 

Les entrees, quant a elles, sont les items qui decrivent le contenu. Leur 
nombre n'est pas limite et elles sont referencees a l'aide de l'element 
<entry> qui contient une serie de noeuds fils pour les decrire et donner 
du sens a l'information syndiquee. Les fils du noeud <entry> sont ainsi 
responsables d'informations telles que le titre, le contenu, le lien vers la 
page originale sur le site Internet, le ou les auteurs, la date de publica- 
tion... et bien plus encore. La encore, certaines donnees sont obliga- 
toires afin de rendre le flux valide. 

Le flux ATOM minimal valide 

Le code ci-dessous donne la structure minimale requise pour rendre un 
flux ATOM valide. II integre entre autres le titre, la date de mise a jour 
ainsi que l'identifiant unique en guise d'informations generales. En ce 
qui concerne les entrees, cet exemple est compose d'une seule et unique 
entree qui contient elle aussi un jeu d'informations obligatoires. Parmi 
elles se trouvent le titre du contenu, son extrait, sa date de mise a jour 
ainsi que son auteur. 

Exemple de flux ATOM minimaliste valide 

<?xml version="1.0" encodi ng="utf-8"?> 
<feed xml ns="http ://www.w3 . org/2005/Atom"> 

<ti tl e>Jobeet</ti tl e> 

<updated>2009-03-17T20:38:43Z</updated> 
<id>afba34a2allabl3eeba5d0a7aa22bbb6120el77b</id> 

<entry> 

<title>Sensio Labs is looking for a Web Developer</tit1e> 
<author> 

<name>Sensio Labs</name> 
</author> 

<i d>d0be2dc421be4f cd0172e5af ceea3970e2f 3d940</i d> 
<updated>2009-03-17T20 : 38 : 43Z</updated> 



<summary> 

You've already developed websites with Symfony and you want 
to work with Open-Source technologies. 

You have a minimum of 3 years 
experience in web development with PHP or Java and you wish 

to 

participate to development of Web 2.0 sites using the best 
frameworks available. 
</summary> 
</entry> 

</feed> 

L'objectif des prochaines pages est de s'appuyer sur ces connaissances de 
base dans le but de generer des flux d'informations plus complexes et 
valides. II s'agit en effet de construire successivement deux flux ATOM 
pour l'application Jobeet. Le premier consiste a creer la liste des dernieres 
offres d'emploi publiees sur le site, toutes categories confondues, alors que 
le second est un flux dynamique propre a chaque categorie de l'application. 



Generer des flux de syndication ATOM 

Afin de s'initier et de comprendre plus concretement comment fonctionne 
le mecanisme des formats de sortie dans Symfony, les pages suivantes 
deroulent pas a pas la creation de flux de syndication au format ATOM. 
Pour commencer, il est primordial de decouvrir et de comprendre de 
quelle maniere est declare un nouveau format de sortie dans Symfony. 

Flux ATOM des dernieres offres d'emploi 
Declarer un nouveau format de sortie 

Dans Symfony, supporter differents formats est aussi simple que de creer 
differents templates dont le nom du fichier integre la particule du format 
souhaite. Par exemple, pour realiser un flux de syndication ATOM des 
dernieres offres d'emploi, un nouveau template nomme 
indexSuccess.atom.php doit etre disponible et contenir par exemple le 
contenu statique suivant. 

Exemple de code ATOM pour les dernieres offres dans le fichier apps/frontend/ 
modules/job/templates/indexSuccess.atom.php 

<?xml version="1.0" encodi ng="utf-8"?> 
<feed xml ns=" http://www.w3 . org/200 5/Atom"> 



<ti tl e>Jobeet</ti tl e> 

<subti tl e>Latest ]obs</subti tl e> 

<link href="" rel="self"/> 

<link href=""/> 

<updatedx/updated> 

<author> 

<name>Jobeet</name> 
</author> 

<id>Unique Id</id> 

<entry> 

<title>Job title</title> 

<link href="" /> 

<id>Um'que id</id> 

<updatedx/updated> 

<summary>Job descri ption</summary> 

<author> 

<name>Company</name> 

</author> 
</entry> 
</feed> 

Le nom du fichier contient la particule atom avant l'extension .php. Cette 
derniere indique a Symfony le format de sortie a renvoyer au client. La 
section suivante donne un rapide rappel sur les conventions de nommage 
des fichiers de template dans un projet. 

Rappel des conventions de nommage des templates 

Dans la mesure ou le format HTML est le plus couramment employe 
dans la realisation d'applications web, l'expression du format de sortie 
. html nest pas obligatoire et peut done etre omise du nom du gabarit 
PHP. En effet, les deux templates indexSuccess.php et 
indexSuccess.html .php sont equivalents pour le framework, e'est pour- 
quoi celui-ci utilise le premier qu'il trouve. 

Pourquoi les noms des templates par defaut sont-ils suffixes avec 
Success ? Une action est capable de retourner une valeur qui indique 
quel template doit etre rendu. Si Taction ne retourne rien, cela corres- 
pond au code ci-dessous qui renvoie la valeur Success : 

J return sfView: : SUCCESS; // == 'Success' 

Pour changer le suffixe d'un template, il suffit tout simplement de 
retourner une valeur differente comme par exemple : 

return sfView: : ERROR; // == 'Error' 
return 'Foo' ; 



De meme, il a ete montre au cours des chapitres precedents que le nom 
du template a rendre pouvait lui aussi etre modifie grace a Templed de la 
methode setTemplate(). 

| $this->setTemplate('foo') ; 

II est temps de revenir a la generation des flux de syndication et de 
modifier le layout de l'application grand public afin quelle dispose des 
liens vers ces derniers. 

Ajouter le lien vers le flux des offres dans le layout 

Par defaut, Symfony modifie automatiquement l'en-tete HTTP 
Content-Type de la reponse en fonction du format. De plus, tous les for- 
mats qui ne sont pas du HTML ne sont pas decores par le layout. Dans 
le cas des flux ATOM par exemple, Symfony retourne au client le type 
de contenu application/atom+xml ; charset=utf-8 dans l'en-tete 
Content-Type de la reponse. 

L'application frontend de Jobeet a besoin d'un hyperlien supplemental 
pour faciliter faeces au flux d'informations par l'utilisateur. Le code ci- 
dessous donne le code HTML et PHP a ajouter dans le pied de page du 
layout de l'application. 

Ajout d'un lien vers le flux de syndication ATOM des offres d'emploi dans le fichier 
apps/frontend/templates/layoutphp 

<li cl ass="feed"> 

<a href="<?php echo url_for('@job?sf_format=atom') ?>">Full 
feed</a> 
</1i> 

LUPvL interne ici creee est la meme que celle qui existe deja pour la liste 
des offres, a ceci pres quelle redefinit la valeur de la variable sf_format 
vue precedemment. Par ailleurs, les navigateurs web sont capables de 
decouvrir et de charger automatiquement les flux de syndication d'une 
application web, a condition que cette derniere integre une balise <1 i nk> 
dans la section <head> de la page. Cette balise speciale informe le client 
qu'une ressource externe a la page courante est disponible a FURL indi- 
quee, et que le type de contenu de cette derniere est du meme type que 
celui specifie dans l'attribut type de la balise. 

Ajout du marqueur du flux ATOM dans la section HEAD du fichier apps/frontend/ 
templates/layout.php 

<link re1="alternate" type="appl ication/atom+xml " title="Latest 
Dobs" 

href="<?php echo url_for('@job?sf_format=atom' , true) ?>" /> 



L'attribut href de la balise <"link> recoit une URL absolue qui est 
generee a l'aide du second argument du helper url_for(). 

Generer les informations globales du flux 

Le premier objectif de la construction du flux consiste a generer les 
informations globales de ce dernier. Pour ce faire, l'en-tete actuel du flux 
doit etre remplace par le code ci-dessous. 

Ajout des informations generates du flux ATOM dans le fichier apps/frontend/ 
modules/job/templates/indexSuccess.atom.php 

<ti tl e>Jobeet</ti tl e> 

<subti tl e>Latest lobs</subti tl e> 

<link href="<?php echo url for('@job?sf f ormat=atom 1 , true) ?>" 

rel="self"/> 

<link href="<?php echo url for(' ©homepage' , true) ?>"/> 
<updatedx?php echo gmstrft^nleC'%Y-%ll1-%dT%H:%M:%SZ , , 
st rtoti me(Doctri ne : : getTabl e ( ' Jobeet Job ' ) ->get LatestPost () -> 
getCreatedAt())) ?></updated> 
! <author> 

<name>]obeet</name> 
</author> 

<idx?php echo shal(url for('@job?sf format=atom' , true)) ?> 

</id> 

Ce template fait usage de la fonction st rtoti me () afin d'obtenir la valeur 
du champ created_at sous la forme d'un timestamp Unix. Pour obtenir 
la date de creation de la derniere offre postee, il suffit de creer la 
methode getl_atestPost() suivante. 

Implementation de la methode getlatestPostO dans la classe JobeeUobTable du 
fichier lib/model/doctrine/JobeetJobTable.class.php 

class JobeetJobTable extends Doctri ne_Tabl e 
{ 

public function getLatestPost() 
{ 

$q = Doctrine Query: :create() 

->from('3obeetDob j'); 
$this->addActiveDobsQuery($q) ; 

return $q->fetchOne() ; 

} 

// ... 

} 

II ne reste a present qua generer toutes les entrees du flux correspon- 
dantes aux dernieres offres publiees sur le site Internet. 
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Generer les entrees du flux ATOM 

Chaque entree est composee d'un titre, d'un contenu au format HTML, 
d'un lien, d'un identifiant unique, d'une date de publication et d'un 
auteur. Toutes ces informations sont bien evidemment issues de la base 
de donnees grace a Taction index du module job. 

Implementation des entrees du flux ATOM dans le fichier apps/frontend/modules/ 
templates/indexSuccess.atom.php 

<?php use helper ('Text') ?> 

<?php foreach ($categories as $category) : ?> 

<?php foreach ($category->getActiveDobs(sfConfig: :get('app max jobs on homepage')) as $job): ?> 

<entry> 
<ti tl e> 

<?php echo $job->getPosition() ?> (<?php echo $job->getLocation() ?>) 

</tit1e> 

<link href="<?php echo ur"l_for(' job show user' , $job, true) ?>" /> 
<idx?php echo shal($job->getId()) ?></id> 

<updatedx?php echo gmstrftime('%Y-%m-%dT%H:%M:%SZ' , strtotime($job->getCreatedAt())) ?> 

</updated> 

<summary type="xhtml "> 
<di v xml ns="http ://www.w3 .org/1999/xhtml "> 
<?php if ($job->getLogo()) : ?> 

<di v> 

<a href="<?php echo $job->getUrl () ?>"> 
<img src="http://<?php echo $sf request->getHost() . '/uploads/jobs/' .$job->getLogo() ?>" 
ait="<?php echo $job->getCompany() ?> logo" /> 

</a> 
</di v> 
<?php endif; ?> 



<di v> 

<?php echo simple format text($job->getDescription()) ?> 

</di v> 



<h4>How to apply?</h4> 



<px?php echo $job->getHowToApp1y() ?></p> 
</di v> 
</summary> 
<author> 

<namex?php echo $job->getCompany() ?x/name> 
</author> 
</entry> 
<?php endforeach; ?> 
<?php endforeach; ?> 

La methode getHost() de l'objet sfWebRequest ($sf_request) retourne 
le serveur courant, qui permet ensuite de construire aisement un lien 
absolu vers le logo de la societe en recherche de nouveaux collaborateurs. 
La fonction gmstrftimeO se charge quant a elle de formater une date 
GMT d'apres le parametrage de la locale du serveur. 
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Jobeet 



6 Total 



Figure 14-2 

Affichage du flux ATOM des dernieres 
offres dans le navigateur Safari 



Web Designer (Paris, France) Extren 
EXTREMEr 

sensio 

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt 
ut labore etdolore magna aliqua. Ut enim ad minim veniam.quis nostrud exercitation ullamco 
laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in. 

Voluptate velitesse cillum dolore eu fugiat nulla pariatur. Excepteur sintoccaecat cupidatat 
non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. 

How to apply? 

Send your resume to tabien.potencier [at] sensio.com 

Read more... 



Web Developer (Paris, France) Sen alo Labs 

SENSIC LABS ^ 



Search Articles: 

(5. ) 

Article Length: 



Sort By: 
Date 

Title 

Source 

New 

Recent Articles: 

All 

Today 
Yesterday 
Last Seven Days 
This Month 
Last Month 

Source: 

Jobeet 



Lors du developpement de flux de syndication, le debogage de ce dernier 
peut etre complexe avec le navigateur comme seul outil, dans la mesure oil 
ce dernier n'affiche pas la source XML par defaut qui est generee. Lideal 
est done de s'appuyer sur des outils plus pratiques en ligne de commande 
tels que curl ou wget qui permettent de recuperer une ressource identifiee 
par son URL. Le contenu textuel du flux ainsi recupere devient alors un 
outil supplementaire pour apprecier les erreurs et les corriger. 



Flux ATOM des dernieres offres d'une categorie 

Lun des objectifs de 1'application Jobeet est d'aider les internautes a 
trouver des offres d'emploi ciblees a leur profil. Partant de ce besoin, il 
s'avere judicieux de produire un flux d'offres d'emploi dedie a chaque cate- 
goric Disposer d'un flux dynamique pour chaque categorie a l'avantage de 
diffuser encore plus de contenus sur Internet mais egalement de satisfaire 
les besoins de chaque utilisateur en termes de pertinence de 1'information. 

Les prochaines sections abordent pas a pas la generation du flux dyna- 
mique de chaque categorie. Le processus de fabrication de ces flux 
s'echelonne sur 5 etapes successives : 

1 mise a jour de la route de la categorie ; 

2 ajout des liens du flux de la categorie dans les templates ; 

3 refactorisation du code de generation des entrees du flux des der- 
nieres offres ; 

4 simplification du template indexSuccess.atom.php du module job ; 

5 generation du template du flux d'une categorie. 
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Pour commencer, il s'agit de mettre a jour la route dediee de la categorie 
afin de rendre le flux publiquement accessible a travers un navigateur web. 

Mise a jour de la route dediee de la categorie 

Pour commencer, la route d'acces au detail d'une categorie doit etre mise 
a jour afin quelle prenne en consideration la variable sf_format comme 
le montre le code ci-dessous. 

Integration du support du format ATOM a la route category du fichier de 
configuration apps/frontend/config/routing.yml 

category: 

url : /category/ : si ug. :sf_format 
class: sfDoctri neRoute 

param: { module: category, action: show, sf_format: html } 
options: { model: JobeetCategory , type: object } 
requi rements : 

sf format: (?: html | atom) 

L'URL de la route se termine desormais par une extension bien precise. 
II s'agit soit de 1' extension . html (par defaut) soit de 1' extension . atom. 
En fonction de la valeur de celle-ci, Symfony choisira automatiquement 
la vue correspondante qu'il doit rendre au client. 

Mise a jour des liens des flux de la categorie 

Desormais, les deux liens qui pointent vers le flux ATOM doivent etre 
mis a jour. Ces liens figurent respectivement dans les fichiers 
i ndexSuccess . php et show/Success . php des modules job et category. 

Extrait de code a remplacer dans le fichier apps/frontend/modules/job/templates/ 
indexSuccess.php 

<div class="feed"> 

<a href="<?php echo url for ('category' , array('sf subject' => 
$category, 'sf format' => 'atom')) ?>">Feed</a> 
</di v> 

Extrait de code a remplacer dans le fichier apps/frontend/modules/category/ 
templates/showSuccess.php 

<div class="feed"> 

<a href="<?php echo url for ('category' , array('sf subject' => 
$category, 'sf format' => 'atom')) ?>">Feed</a> 
</di v> 



Factoriser le code de generation des entrees du flux 

La derniere etape du parcours consiste a creer le tempate 
showSuccess.atom.php. Le flux de syndication a bien evidemment besoin 
de la liste des offres d'emploi ; c'est pourquoi il semble opportun de refac- 
toriser le code qui genere les entrees du flux. II convient done d'ajouter un 
nouveau template partiel _list.atom.php au projet, qui se charge de 
generer toutes les entrees du flux. De la meme maniere qu'avec le format 
HTML, les templates partiels sont specifiques au format utilise. 

Contenu du fichier apps/frontend/job/templates/Jist.atom.php 

<?php use helper ('Text') ?> 

<?php foreach ($jobs as $job) : ?> 

<entry> 

<tit1ex?php echo $job->getPosition() ?> (<?php echo $job-> 

getLocationO ?>)</title> 
<link href="<?php echo url for(' job show user' , $job, true) 

?>" /> 

<idx?php echo shal($job->getId()) ?></id> 

<updatedx?php echo gmstrftime( , %Y-%m-%dT%H:%M:%SZ' , 
strtotime($job->getCreatedAt())) ?> 

</updated> 
<summary type="xhtml "> 
<di v xml ns="http : //www. w3 . org/1999/xhtml "> 
<?php if ($job->getLogo()) : ?> 

<di v> 

<a href="<?php echo $job->getUr1 () ?>"> 
<img src="http://<?php echo $sf request-> 

getHost(). '/uploads/jobs/' . $job->getLogo() ?>" 
alt="<?php echo $job->getCompany() ?> logo" /> 

</a> 
</di v> 
<?php endif; ?> 

<di v> 

<?php echo simple format text($job->getDescription()) ?> 

</di v> 

<h4>How to app1y?</h4> 

<px?php echo $job->getHowToApp1y() ?x/p> 
</di v> 
</summary> 
<author> 

<namex?php echo $job->getCompany() ?></name> 
</author> 
</entry> 
<?php endforeach; ?> 



Simplifier le template indexSuccess.atom.php 

Maintenant que le code est proprement isole dans un template partiel, le 
template indexSuccess.atom.php du module job peut a son tour etre 
simplifie en profitant de cette modification. 

Contenu du fichier apps/frontend/modules/job/templates/indexSuccess.atom.php 

<?xm1 version="1.0" encodi ng="utf-8"?> 
<feed xml ns=" http://www.w3 .org/200 5/Atom"> 

<ti tl e>Jobeet</ti tl e> 

<subti t1e>Latest Jobs</subtit1e> 

<link href="<?php echo url for('@job?sf f ormat=atom ' , true) 
?>" rel="self"/> 

<link href="<?php echo url for ('©homepage ' , true) ?>"/> 
<updatedx?php echo gmstrftime( , %Y-%m-%clT%H:%M:%SZ' , 
strtotime(Doctrine: :getTab1e( ' JobeetDob')-> 

getLatestPost()->getCreatedAt())) ?></updated> 

<author> 

<name>Jobeet</name> 
</author> 

<idx?php echo shal(ur1 for('@job?sf_format=atom' , true)) 

?></id> 

<?php foreach ($categories as $category) : ?> 

<?php include partial ('job/list' , arrayC jobs' => $category-> 
getActiveJobs(sfConfig: :get('app max jobs on homepage')))) ?> 
<?php endforeach; ?> 

</feed> 



Generer le template du flux des offres d'une categorie 

Le template showSuccess.atom.php du module category est sensible- 
ment le meme que celui des dernieres offres, a ceci pres que les informa- 
tions globales du flux concernent cette fois-ci la categorie. II s'agit done 
d'adapter les informations d'en-tete du flux avec celles correspondant a 
la categorie demandee. Le code ci-dessous presente le contenu du fichier 
showSuccess . atom . php. 

Le fichier apps/frontend/modules/category/templates/showSuccess.atom.php 

<?xml version="1.0" encodi ng="utf-8"?> 
<feed xml ns=" http://www.w3 . org/200 5/Atom"> 

<title>3obeet (<?php echo $category ?>)</title> 

<subti t1e>Latest Jobs</subtit1e> 

<link href="<?php echo url for ('category ' , array('sf subject' 
=> $category, 'sf format' => 'atom'), true) ?>" rel="self" /> 

<link href="<?php echo url for ('category ' , array('sf subject' 
=> $category) , true) ?>" /> 



<updatedx?php echo gmstrftime( , %Y-%m-%dT%H:%M:%SZ' , 
strtotime($category->getLatestPostO->getCreatedAt())) ?> 

</updated> 
<author> 

<name>Jobeet</name> 
</author> 

<idx?php echo shal(ur1 for ('category' , array('sf subject' => 
$category) , true)) ?></id> 

<?php incl ude partial (' job/list ' , arrayC jobs' => 

$pager->getResu"lts())) ?> 

</feed> 

Ce template fait appel a la methode getLatestPost() qui renvoie la 
toute derniere offre postee dans cette categoric Cette nouvelle methode 
n'existe pas encore et doit done etre implemented dans la classe 
JobeetCategory comme le montre le morceau de code ci-dessous. 

Implementation de la methode getLatestPostO de la classe JobeetCategory dans le 
fichier lib/model/doctrine/JobeetCategory.class.php 

class JobeetCategory extends BaseJobeetCategory 
{ 

public function getLatestPostO 
{ 

$jobs = $this->getActive3obs(l) ; 
return $jobs[0] ; 

} 

// ... 

} 

La methode getActiveJobsO retourne une collection d'objets JobeetJob 
bien qu'il n'y ait qu'un seul enregistrement recupere. C'est pour cette 
raison qu'il faut utiliser la syntaxe ArrayAccess sur l'objet 
Doctri ne_Col lection afin de renvoyer l'objet unitaire. La classe 
Doctri ne_Col lection implemente egalement une methode getFirstO 
qui permet d'obtenir le premier objet de la collection, ce qui revient 
exactement au meme que la syntaxe ArrayAccess employee ici. 
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Figure 14-3 Affichage du flux ATOM des offres d'une categorie dans le navigateur Safari 



En resume... 

Comme pour la plupart des fonctionnalites de Symfony deja decrites, 
l'ajout de flux de syndication aux applications web s'est effectue sans 
effort, et ceci grace au support natif des formats de sortie. Ce chapitre a 
done permis de faciliter la vie de 1'utilisateur en recherche d'emploi, en 
lui fournissant un moyen simple et efficace de se tenir directement 
informe, depuis son navigateur ou son agregateur favori, des dernieres 
offres d'emploi publiees. 

Le chapitre suivant va plus loin dans la maniere d'exposer les offres aux 
internautes, en leur fournissant un service web ( Web Service) . . . 
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Construire des services web 



MOTS-CLES 



Aujourd'hui, de plus en plus de sites modernes proposent 
des services web aux developpeurs afin que ces derniers soient 
capables d'integrer leur contenu aisement dans leurs propres 
applications web. 

La puissance du routage de Symfony ainsi que le support natif 
des formats de sortie apportent une solution efficace et rapide 
pour la conception de services web. 



► Formats XML, JSON et YAM L 

► Envoi d'e-mails 

► Tests fonctionnels 

► REST 



Avec l'arrivee des flux de syndication ATOM dans Jobeet, les utilisateurs 
en recherche d'emploi ont desormais la possibilite d'etre tenus informes 
de la publication de nouvelles offres en temps reel. C'est un excellent 
debut pour ameliorer leur confort d'utilisation mais c'est surtout un 
moyen efficace de diffuser de l'information a travers Internet pour lui 
garantir une meilleure visibilite. 

De l'autre cote, lorsqu'une nouvelle offre d'emploi est postee, il convient 
idealement de lui faire profiter de la meilleure exposition possible. En effet, 
plus l'annonce est syndiquee sur un reseau de petits sites, et plus elle aura de 
chance d'attirer les meilleurs profils. C'est tout le pouvoir de la « longue 
traine » {long tail), ce qui signifie ici que meme les petits sites Internet ou 
weblogs representent potentiellement une part non negligeable dans la 
reussite de l'offre. Grace aux services web qui seront developpes tout au 
long de ce chapitre, les partenaires et les affilies seront capables d'afficher 
sur leurs sites web les toutes dernieres offres d'emploi publiees. 

Concevoir le service web des offres 
d'emploi 

L'objectif de ce quinzieme chapitre est de realiser pas a pas un service 
web a destination des developpeurs. Ce service sera accessible au moyen 
d'une interface de programmation applicative (API) simple reposant sur 
l'appel d'URLs et sur la recuperation d'informations dans differents for- 
mats de sortie tels que le XML, le JSON ou bien encore le YAML. La 
conception de ce service web se deroule en plusieurs etapes successives 
qui necessitent entre autres de declarer la route de l'API, d'implementer 
Faction a executer ou bien encore de construire les templates relatifs a 
chaque format de sortie demande. Pour commencer en douceur, il con- 
vient de preparer quelques jeux de donnees initiales. 

Preparer des jeux de donnees initiales des affilies 

Le troisieme chapitre a ete l'occasion d'etablir et de decouvrir le schema 
de description de la base de donnees. Ce dernier definit deux entites de 
modele qui n'ont pas encore ete exploiters jusqu'a present : 
JobeetAffiliate et JobeetCategoryAff i 1 i ate. La table 
jobeet_affiliate stocke les informations du site Internet partenaire 
tandis que la relation jobeet_category_affiliate se contente de garder 
en memoire la liste des categories auxquelles est affilie ce dernier. 

Comme avec les categories et les offres d'emploi, il est bon de demarrer 
le developpement d'une nouvelle fonctionnalite en preparant quelques 



jeux de donnees initiales. Le code ci-dessous declare deux sites Internet 
partenaires et leur associe a chacun une liste de categories. 

Jeu de donnees initiales du fichier data/fixtures/affiliates.yml 

JobeetAffiliate: 



sensio_l abs : 

url : http://www.sensio-labs.com/ 

email : fabien.potencier@example.com 

is_active: true 

token: sensio_labs 
JobeetCategories: [programming] 

symfony : 

url : http://www.symfony-project.org/ 

email : fabien.potencier@example.org 

is_active: false 

token: symfony 



JobeetCategories: [design, programming] 

Comme le montre le contenu de ce fichier YAML, la creation d'enregis- 
trements pour une relation « many-to-many » est aussi simple que 
definir un tableau dont les valeurs sont les noms des enregistrements des 
entites en relation. Le contenu du tableau de categories correspond au 
nom des objets definis dans les fichiers de donnees. Les objets peuvent 
ainsi etre lies entre eux a divers endroits et dans differents fichiers a con- 
dition qu'ils aient tous bien ete declares en premier. 

Pour des raisons de simplification des tests, les jetons de chaque affilie 
sont codes en dur dans le fichier YAML. Lorsque le site sera en produc- 
tion, ces derniers devront bien evidemment etre generes automatique- 
ment au moment ou l'utilisateur postulera pour un compte. 

Implementation de la methode preValidateO dans la classe JobeetAffiliate du fichier 
lib/model/doctrine/JobeetAffiliate.class.php 

class JobeetAffiliate extends BaseJobeetAffi 1 i ate 
{ 

public function preVal idate($event) 
{ 

$object = $event->getInvoker() ; 

if (!$object->getToken()) 
{ 

$object->setToken(shal($object->getEmail () . rand(lllll, 99999))) ; 

} 

} 



// 

} 



La methode preValidateO d'un objet Doctrine est toujours executee 
avant que 1' objet ne soit serialise en base de donnees. Elle a pour role de 
controler que l'objet courant est valide et qu'il peut etre sauvegarde en 
base de donnees. La methode getlnvokerO de l'objet Doctrine_Event, 
lui-meme passe en parametre de la methode preValidateO, retourne 
l'objet JobeetAffiliate. La condition qui lui succede verifie si le jeton 
est deja defini. S'il ne Test pas encore, il est alors genere automatique- 
ment a partir de l'adresse e-mail et d'une valeur aleatoire. Grace a ce 
mecanisme, le champ token de la table jobeet_affiliate ne peut rester 
nul, et done l'objet reste valide. 

Au final, il ne reste plus qua charger les jeux de donnees initiales dans la 
base de donnees au moyen de la commande Symfony doctri ne : data-1 oad. 

| $ php symfony doctrine: data-load 

Construire le service web des offres d'emploi 
Declaration de la route dediee du service web 

Comme toujours, la premiere bonne pratique a mettre en oeuvre 
lorsqu'une nouvelle fonctionnalite est sur le point d'etre implementee, 
est de declarer une route dediee pour la rendre accessible. Dans le cas 
present, il s'agit de definir une URL propre a chaque affilie qui fait usage 
de la variable speciale sf_format vue au cours du precedent chapitre. Le 
jeton qui vient tout juste d'etre cree pour le modele JobeetAffiliate sert 
effectivement a rendre la route dependante de l'affilie. 

La route ci-dessous implements done ce jeton ainsi que la variable spe- 
ciale sf_format afin de determiner dans quel format les informations 
doivent etre delivrees par l'API. 

Declaration de la route apijobs dans le fichier apps/frontend/config/routing.yml 

api_jobs : 

url : /api/: token/jobs . : sf_format 

class: sfDoctri neRoute 

param: { module: api, action: list } 

options: { model: JobeetJob, type: list, method: getForToken } 
requi rements : 

sf format : (? : xml | j son | yaml ) 

Cette route se termine par la variable sf_format qui, d'apres les restric- 
tions qui lui sont appliquees, peut prendre l'une des valeurs parmi xml, 
json ou bien yaml. 



Implementer la methode getForToken() de I'objet JobeetJobTable 

De plus, cette route a besoin d'une methode getForTokenO qui est 
appelee lorsque Taction recupere la collection d'objets en relation. Dans 
la mesure oil il faut s' assurer que l'affiiie est bien active, le comportement 
par defaut de la route doit etre surcharge. 

Implementation de la methode getForToken() dans le fichier lib/model/doctrine/ 
JobeetJobTable.class.php 

class JobeetJobTable extends Doctri ne_Tabl e 
{ 

public function getForToken(array $parameters) 
{ 

$affi"liate = Doctrine: :getTab1e(' UobeetAf filiate') 

->f i ndOneByToken ($parameter s [ ' token ' ] ) ; 
if (!$affiliate || ! $af fil iate->getIsActive()) 
{ 

throw new sfError404Exception(sprintf('Affi"liate with 
token "%s" does not exist or is not activated.', 
$parameters[' token'])) ; 
} 

return $af fil iate->getActiveJobs() ; 

} 

// ... 

} 

La methode getForTokenO se charge de recuperer un objet 
JobeetAffiliate a partir de sonjeton unique. Si le jeton hexiste pas dans 
la base de donnees, alors une exception de type sfError404Exception est 
levee afin d'etre automatiquement convertie en reponse 404 par Symfony. 
Lancer ce type d'exception est la maniere la plus simple de generer des 
pages d'erreur 404 depuis une classe de modele. 

II faut aussi remarquer que getForTokenO fait appel a la methode vir- 
tuelle fi ndOneByToken O de la classe JobeetAff i 1 i ateTabl e. Doctrine 
permet de recuperer un objet unique d'une table en utilisant la methode 
findOneBy*() oil * est le nom du champ dans la table qui sert de critere 
de restriction (clause WHERE de la requete SQL). Ces methodes virtuelles 
sont automatiquement generees par Doctrine a l'aide de l'implementa- 

tion de la methode magique cal 1 () de PHP. C'est grace a cette der- 

niere qu'il est rendu possible d'appeler des methodes non definies 
explicitement dans la classe de I'objet. 

Implementer la methode getActiveJobs() de I'objet JobeetAffiliate 

D'autre part, la methode getForTokenO utilise une nouvelle methode 
getActiveJobsO afin de retourner la liste des offres actives courantes. 



Implementation de la methode getActiveJobsO dans la classe JobeetAffiliate du 
fichier lib/model/doctrine/JobeetAffiliate.class.php 



class JobeetAffiliate extends BaseJobeetAff i 1 i ate 
{ 

public function getActiveJobsO 
{ 

$q = Doctrine Query: :create() 
->se1ect('j.*') 
->f rom( ' JobeetJob j') 
->1eftJoin(' j . DobeetCategory c') 
->1 eftJoin( ' c . DobeetAf f il iates a' ) 
->where('a.id = ?', $this->getld()) ; 

$q = Doctrine: :getTab1e(' Dobeet Job') 
->addActiveJobsQuery($q) ; 

return $q->execute() ; 

} 

// ... 

} 

La derniere etape consiste a mettre en place Faction de l'API et ses tem- 
plates. Pour ce faire, il suffit de generer un nouveau module a l'aide de la 
commande generate:module. 

$ php symfony generate: module frontend api 

Dans la mesure oil Taction i ndex par defaut n'est pas utile au reste de 
l'application, elle peut etre supprimee en toute securite de la classe 
d'actions, ainsi que son template associe indexSuccess.php. 

Developper le contrdleur du service web 
Implementer I'action executeListO du module api 

Tous les formats de sortie de la route api _ jobs partagent la meme action 
list du module api. En sachant cela, il convient seulement d'imple- 
menter la methode executeListO puis de construire les templates pro- 
pres a chaque format de sortie definis pour la variable sf_format. 

Le corps de cette methode ne pose aucune difficulte particuliere dans la 
mesure ou cette derniere se charge de recuperer la liste des objets 
JobeetJob a partir de la route appelee, puis de representer chaque objet 
sous la forme d'un tableau avant de stocker ce dernier dans un autre 
tableau passe au template correspondant. 



Implementation de la methode executeListeO dans le fichier apps/frontend/ 
modules/ api/ actions/actions.class.php 

public function executeLi st(sfWebRequest Srequest) 
{ 

$this->jobs = arrayO; 

foreach ($this->getRoute()->getObjects() as $job) 
{ 

$this->jobs[$this->generateUrl ( ' job_show_user ' , $job, 
true)] = $job->asArray($request->getHost()) ; 

} 

} 



Implementer la methode asArrayO de JobeetJob 

Au lieu de passer un tableau d'objets JobeetJob aux templates comme 
c'est le cas d'habitude, Faction transmet un tableau de chaines de carac- 
teres. Comme Taction est partagee par trois templates differents, la 
logique metier de traitement des valeurs a ete mutualisee ailleurs dans la 
methode JobeetJob: :asArray(). 

Implementation de la methode asArrayO dans la classe JobeetJob du fichier lib/ 
model/doctrine/JobeetJob.class.php 

class JobeetJob extends BaseJobeet Job 
{ 

public function asArray($host) 
{ 

return arrayC 

'category' => $this->getJobeetCategory()->getName() , 
'type' => $this->getType() , 

'company' => $this->getCompany() , 

'logo' => $this->getLogo() ? ' http://' . $host . '/ 

uploads/ jobs/' .$this->getLogo() : null, 
' urV => $thi s->getUrl () , 

'position' => $this->getPosition() , 
'location' => $this->getLocation() , 
'description' => $this->getDescription() , 
'how to apply' => $this->getHowToApp1y() , 
'expires_at' => $this->getCreatedAt() , 

); 

} 

// ... 

} 

Le code metier de Faction est a present completement implements, et la 
prochaine etape consiste alors a developper le template listSuccess.php 
pour chaque format de sortie desire. 
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Construction des templates XML, JSON et YAML 

Cette section aborde la generation des templates pour les trois formats 
de sortie possibles. Les templates pour le format XML et JSON sont 
relativement simples a comprendre et a mettre en oeuvre, c'est pourquoi 
il n'y aura que tres peu d'explications a leur egard. En revanche, le 
format YAML necessitera d'approfondir quelques notions subtiles 
comme la gestion des erreurs en fonction des environnements. 

Le format XML 

Le format XML est aussi simple a gerer que le HTML puisqu'il s'agit 
de creer un nouveau template contenant la generation du code XML a 
renvoyer au client. Dans le cadre de Jobeet, il s'agit d'aboutir a un fichier 
XML similaire a la maquette suivante : 

<?xml version="1.0" encodi ng="utf-8"?> 
<jobs> 

<job url="http : //www. jobeet .org/en/ job/extreme- sensi o/pari s- 
f rance/2/web-desi gner"> 

<category>design</category> 
<type>part-time</type> 

<1 ogohttp: //www. jobeet .org/upl oads/jobs/ext reme- 
sensi o . gi f </l ogo> 

<1 ocati on>Pari s , France</1 ocati on> 
<description> 

Lorem ipsum dolor sit amet, consectetur adipisicing elit, 
sed do eiusmod tempor incididunt ut labore et dolore magna 
aliqua. Ut enim ad minim veniam, quis nostrud exercitation 
, ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis 
aute irure dolor in reprehenderi t in. 

Voluptate velit esse cillum dolore eu fugiat nulla pariatur. 
Excepteur sint occaecat cupidatat non proident, sunt in culpa 
qui officia deserunt mollit anim id est laborum. 
</descri ption> 

<how_to_apply>Send your resume to fabi en . potenci er [at] 
sensi o . com</how_to_appl y> 

<expi res_at>2009-05-16</expi res_at> 
</job> 
<!-- ... -> 
</jobs> 

Ce gabarit XML ne pose aucune difficulte a generer. En effet, les noms 
des balises correspondent aux cles du tableau PHP renvoye par la 
methode asArrayC). Seules quelques lignes de code PHP suffisent a 
construire un tel template comme le montre le code ci-dessous. 



Contenu du template apps/frontend/modules/api/templates/listSuccess.xml.php 



<?xml version="1.0" encodi ng="utf-8"?> 
<jobs> 

<?php foreach ($jobs as $ur1 => $job): ?> 

<job url="<?php echo $url ?>"> 
<?php foreach ($job as $key => $value): ?> 

«?php echo $key ?»<?php echo $va"lue ?></<?php echo $key 

?» 

<?php endforeach; ?> 

</job> 
<?php endforeach; ?> 

</jobs> 

Seulement deux instructions foreach () suffisent au parcours du tableau 
$jobs. La premiere itere sur la liste des offres tandis que la seconde se 
charge de traverser les proprietes de chacune d'entre elles afin d'en 
generer les bons couples balise/contenu. 

Le format JSON 

JSON (JavaScript Object Notation), est un format de donnees standard 
derive de la notation des objets du langage ECMAScript, et qui a pour 
objectif premier de structurer de 1'information a l'aide d'une syntaxe 
simple et lisible par les developpeurs. Le format JSON permet de decrire 
differents types de structures de donnees comme les objets, les tableaux, 
les entiers, les chaines de caracteres, les booleens... 

LAPI de Jobeet supporte nativement le format JSON. II s'agit done a 
present de developper le template correspondant capable de generer une 
reponse au format JSON identique au code ci-dessous. 

[ 
{ 

"url " : "http : //www. jobeet . org/en/job/extreme-sensio/ 

pari s-f rance/2/web-designer" , 
"category": "design", 
"type": "part-time", 

"1 ogo" : "http : \/\/www. jobeet . org\/upl oads\/jobs\/ 

extreme-sensio.gif", 
"location": "Paris, France", 

"description": "\tl_orem ipsum dolor sit amet, consectetur 
adipisicing elit, sed do \n\t\tei usmod tempor incididunt ut 
labore et dolore magna aliqua. Ut \n\t\tenim ad minim veniam, 
quis nostrud exercitation ullamco laboris \n\t\tnisi ut aliquip 
ex ea commodo consequat. Duis aute irure dolor \n\t\tin 
reprehenderit i n .\n\t\tVol uptate velit esse cillum dolore eu 
fugiat nulla pariatur. \n\t\tExcepteur sint occaecat cupidatat 
non proident, sunt in culpa \n\t\tqui officia deserunt moll it 
anim id est laborum.", 



"how_to_apply" : "Send your resume to f abi en . potenci er [at] 
sensio.com" , 

"0": "2009-05-16" 

} 
] 

La generation de ce type de resultat JSON est realisee au moyen des 
quelques lignes de code PHP qui suivent, et notamment grace a la fonc- 
tion native json_encode() du langage PHP. 

Contenu du template apps/frontend/modules/api/templates/listSuccess.json.php 

[ 

<?php $nb = count($jobs) ; $i = 0; foreach ($jobs as $ur1 => 
$job): ++$i ?> 

{ 

"url": "<?php echo $ur1 ?>", 
<?php $nbl = count($job); $j = 0; foreach ($job as $key => 
$va"lue): ++$j ?> 

"<?php echo $key ?>": <?php echo json encode ($ value) . ($nbl == 
; $j ? " : ',')?> 

<?php endforeach; ?> 

}<?php echo $nb == $i ? " : ' , ' ?> 

<?php endforeach; ?> 

] 



Le format YAML 

Parametrer les caracteristiques de la reponse 

Symfony configure automatiquement certains parametres tels que les en- 
tetes de type de contenu {Content-Type) ou bien encore la deactivation du 
layout pour les formats de sortie standards integres au framework. Le 
format YAML ne fait pas partie de la liste des formats standards supportes 
nativement, c'est pourquoi les en-tetes HTTP ainsi que la suppression du 
layout doivent etre geres manuellement dans les actions. 

class api Actions extends sf Actions 
{ 

public function executeLi st(sfWebRequest Srequest) 
{ 

$this->jobs = arrayO ; 

foreach ($thi s->getRoute()->getObjects() as $job) 
{ 

$thi s->jobs [$thi s->generateUrl ( 1 job_show_user ' , $job , 

true)] = $job->asArray($request->getHost()) ; 

} 



swi tch ($request->getRequestFormat () ) 
{ 

case 'yaml ' : 

$this->setLayout(fa1se) ; 

$thi s->getResponse()->setContentType( ' text/yaml ' ) ; 
break; 

} 

} 

} 

L'instruction swi tch () ci-dessus teste la valeur du format de sortie 
demande. Si celui-ci repond a la valeur yaml alors le layout est desactive 
pour ne pas decorer le template de Taction, et l'en-tete HTTP Content- 
Type de la reponse est fixe a la valeur text/yami . 

Construire le template de generation de la sortie YAML 

Le template au format YAML n'est guere plus complexe a mettre en 
oeuvre que les deux precedents dans la mesure oil Symfony fournit tous 
les outils necessaires a la conversion de tableaux PHP en chaines de 
caracteres YAML. 

Contenu du template apps/frontend/modules/api/templates/listSuccess.yaml.php 

<?php foreach (Sjobs as $ur1 => $job) : ?> 

url : <?php echo $url ?> 

<?php foreach ($job as $key => Svalue): ?> 

<?php echo $key ?>: <?php echo sfYaml : : dump ($ value) ?> 

<?php endforeach; ?> 
<?php endforeach; ?> 

Si Ton tente d'appeler le service web avec un jeton invalide, une page 
d'erreur 404 au format XML ou JSON sera levee. Or, le format YAML 
n'est pas un format supporte nativement par le framework. II en resulte alors 
que ce dernier ne sait pas quel template rendre au client. La section suivante 
explique comment definir les pages d'erreur 404 pour le format YAML en 
tenant compte des environnements de developpement et de production. 

Generation des pages d'erreur 404 en fonction de I'environnement 

A chaque fois qu'un nouveau format est cree, un template d'erreur 
associe doit egalement etre prepare. Symfony se servira en effet de ce 
template pour rendre les pages d'erreur 404 ainsi que toutes les autres 
exceptions levees. Or, le rendu d'une erreur ou d'une exception n'est pas 
le meme selon que l'application est executee en environnement de deve- 
loppement ou de production. 



De ce fait, il est necessaire de gerer ces deux cas de figure en fournissant 
deux templates distincts : config/error/exception .yaml . php pour le 
debogage et config/error/error. yarn! .php pour la production. Sur- 
charger les pages par defaut d'erreur 404 ou d'exception de Symfony 
revient simplement a creer un fichier dans le repertoire config/error/. 

Contenu du template d'affichage des exceptions du format YAML dans le fichier 
config/error/exception.yaml.php 

<?php echo sfYaml : : dump(array( 
'error' => array( 

'code' => $code, 

'message' => Smessage, 
'debug' => array( 
'name' => $name, 
'message' => Smessage, 
'traces' => Straces, 

), 

)), 4) ?> 

Contenu du template d'affichage des erreurs 404 du format YAML dans le fichier 
config/error/error.yaml.php 

<?php echo sfYaml :: dump(array( 
'error' => array( 

'code' => Scode, 

'message' => Smessage, 
))) ?> 

La creation de ces deux templates d'erreur ne suffit pas pour pouvoir les 
tester. II manque en effet la mise en place d'un layout dedie au format 
YAML. 



Contenu du layout propre au format YAML dans le fichier apps/frontend/templates/ 
layout.yaml.php 



| <?php echo $sf_content ?> 



Figure 15-1 

Recuperation d'une page d'erreur 404 
au format YAML en environnement 
de developpement 
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-Avork/jobeet $ curt http://jobeet.localnosVfrorrterid_dev.php/api/sensio_lob/jotos.yaml 
error: 
code: 404 

message: 'Affiliate with token "sensio_lab" does not exist or is not activated.' 
debug: 

name: sfError404Exception 

message: 'Affiliate with token "sensiojlab" does not exist or is not activated.' 
traces: 

- 'at O in SF_ROOT_DIR/lib/rrKxlel/JobeetJobPeer.php line 12' 

- ' at JobeetJobPeer : : getForToken(array( ' ' token ' ' .*gt ; ' ' sensiojlab " , " sf .format ' ' 

- 'at call_user_func(array("JobeetJobPeer" , "getForToken"), arrayC"token" ^Igt 

- 'at sfOojectRoute->getObjectForParometersCarrayC' 'module' ' -> "api", "action 
sfPropelPlugin/lib/routing/sfPropelRoute. class. php line 1W 

- 'at sfPropelRoute->getObjectsForParametersCarrayC' 'module' ' => "api", "actio 
/sfObjectRoute. class. php line 141' 

- 'at sfflbiectRnute-xseHTbiertsn in SF ROOT DTR/anns/f rontpnd/modul es/aoi /arti ons/a 



Le service web est maintenant entierement fonctionnel et pret a Templed. 
Cependant, il ne sera mis en production qu'apres lui avoir fait subir quel- 
ques series de tests fonctionnels pour en valider le bon comportement. 

Ecrire des tests fonctionnels pour valider le 
service web 

Comme toujours, les tests fonctionnels necessitent des jeux de donnees. La 
premiere etape consiste done a copier les fichiers de donnees initiales du 
modele JobeetAffiliate depuis le repertoire data/fixtures vers test/ 
fixtures. Une fois cette manipulation accomplie, le contenu du fichier 
autogenere api Acti onsTest . php peut etre remplace par le code suivant : 

Scenarios de tests fonctionnels du module api dans le fichier test/functional/ 
frontend/apiActionsTestphp 

incl ude(di rname( FILE ) .'/■■/■ ./bootstrap/functional . php') ; 

Sbrowser = new JobeetTestFunctional (new sf BrowserO) ; 
$browser->loadData() ; 

$browser-> 

info('l - Web service security')-> 

info(' 1.1 - A token is needed to access the service')-> 

get('/api/foo/jobs.xml ')-> 

wi th ( ' response ' ) ->i sStatusCode(404) -> 

info(' 1.2 - An inactive account cannot access the web 
service ')-> 

getC/api/symfony/jobs.xml ')-> 

wi th ( ' response ' ) ->i sStatusCode(404) -> 

info('2 - The jobs returned are limited to the categories 
configured for the affiliate')-> 
get('/api/sensio_labs/jobs.xm1 ')-> 
with(' request ' )->isFormat('xin1 ')-> 
with(' response ')->checkElement(' job' , 32)-> 

infoC'3 - The web service supports the JSON format ')-> 
get( ' /api /sensio_labs/ jobs . json ' )-> 
with(' request ' )->isFormat(' json') -> 

wi th ( ' response ' ) ->contai ns( ' "category" : "Programmi ng" ' ) -> 

info('4 - The web service supports the YAML format')-> 
get ( ' /api /sensi o_l abs/ jobs . yaml ' ) -> 
with(' response ')->begin()-> 

isHeader('content-type' , ' text/yam"! ; charset=utf-8')-> 



contai ns ( ' category : Programmi ng ' ) -> 
endO 

L'ensemble de cette suite de tests fonctionnels est suffisamment explicite 
pour ne pas etre detaillee davantage dans la mesure ou la plupart des 
concepts ici presents ont deja ete expliques au chapitre 9. II faut cepen- 
dant remarquer l'utilisation de deux nouvelles methodes, isFormatO et 
contai ns(), qui controlent respectivement le format de sortie attendu et 
le contenu de la reponse lorsque celle-ci ne peut etre analysee a l'aide du 
DOM (et de selecteurs CSS 3). Enfin, la methode isHeaderO du test 
numero 4 s'assure que la valeur de l'en-tete de la reponse correspond 
bien a la chaine text/yml ; charset=utf-8. 



Formulaire de creation d'un compte 
d'affiliation 

Le service web est enfin pret a etre consomme par les sites Internet par- 
tenaires. Cependant, l'utilisation du service oblige l'affilie a s'enregistrer 
aupres de l'application Jobeet afin de se voir delivrer un jeton unique. 
Cette operation est bien evidemment gratuite et realisable via un court 
formulaire d'inscription. La section qui suit decrit en cinq etapes succes- 
sives comment mettre en oeuvre et tester cette nouvelle fonctionnalite. 

Declarer la route dediee du formulaire d'inscription 

Comme toujours, l'activation d'une nouvelle route dediee pour la ressource 
est la premiere etape a mettre en ceuvre. II s'agit ici de declarer une nouvelle 
collection de routes Doctrine capable de gerer un ensemble d' actions neces- 
saires au bon fonctionnement du mecanisme d'inscription des affilies. 

Declaration de la route affiliate dans le fichier apps/frontend/config/routing.yml 

affiliate: 

class: sfDoctrineRouteCollection 
options : 

model: JobeetAff i 1 i ate 

actions: [new, create] 

object_actions : { wait: get } 

Le code ci-dessus definit une collection de routes Doctrine dans laquelle 
figure une nouvelle option de configuration : actions. Dans la mesure ou 
le processus d'inscription n'a pas besoin des sept actions par defaut definies 
dans la route, l'option actions force la route a n'etre active que pour les 



actions create et new. La route additionnelle wait sera utilisee pour 
donner des feedbacks sur son compte a l'affilie en attente de validation. 

Generer un module d'amorcage 

La seconde etape traditionnelle dans ce processus consiste a generer un 
module dedie pour cette nouvelle fonctionnalite. Bien evidemment, il 
convient de faire usage de la commande doctri ne: gene rate-module pour 
accomplir cette tache. 

$ php symfony doctri ne : generate-modul e frontend affiliate 
JobeetAf f i 1 i ate --non-verbose-templ ates 



Construction des templates 

La tache doctrine: generate-modul e genere les sept actions classiques 
par defaut ainsi que tous leurs templates correspondants. Tous les tem- 
plates du repertoire templates/ peuvent etre supprimes a l'exception des 
fichiers _form.php et newSuccess . php. Pour ces fichiers restants, leur 
contenu respectif doit etre remplace par ceux qui suivent. 

Contenu du fichier apps/frontend/modules/affiliate/templates/newSuccess.php 

<?php use stylesheet ('job. ess') ?> 

<hl>Become an Aff i 1 i ate</hl> 

<?php include partial (' form' , array('form' => $form)) ?> 

Contenu du fichier apps/frontend/modules/affiliate/templates/Jorm.php 

<?php include stylesheets for form($form) ?> 
<?php include javascripts for form($form) ?> 

<?php echo form tag for ($form, 'affiliate') ?> 

<table id=" job_form"> 
<tfoot> 
<tr> 

<td colspan="2"> 

<input type=" submit" value="Submit" /> 
</td> 
</tr> 
</tfoot> 
<tbody> 

<?php echo $form ?> 
</tbody> 
</table> 
</form> 



Le template waitSuccess.php peut a son tour etre cree comme le pre- 
serve le code ci-dessous. 

Contenu du fichier apps/frontend/modules/affiliate/templates/waitSuccess.php 

<hl>Your affiliate account has been created</hl> 

<div sty1e=" padding: 20px"> 
Thank you! 

You will receive an email with your affiliate token 
as soon as your account will be activated. 
</di v> 

, Last, change the link in the footer to point to the affiliate 
module: 

// apps/f rontend/templ ates/1 ayout . php 
<li cl ass="l ast"> 

<a href="<?php echo url for('@affil iate new') ?>">Become an 
affiliate</a> 
</li> 

Les templates sont desormais prets. II ne leur manque plus que l'imple- 
mentation de leur action associee pour rendre le tout fonctionnel. 

Implementer les actions du module affiliate 

La plupart du code autogenere dans le fichier actions. class. php n'est 
pas utile au reste de l'application. De ce fait, tout le code de ce fichier 
peut etre retire a l'exception des methodes executeNewO, 
executeCreateO, et processForm(). L'URL de redirection de Faction 
processFormO doit quant a elle etre modifiee. 

Modification de I'URL de redirection dans le fichier apps/frontend/modules/ 
affiliate/actions/actions.class.php 

$this->redi rect($thi s->generateUrl ( ' af f i 1 i ate_wai t ' , 
$jobeet_affiliate)) ; 

De son cote, Taction wait reste triviale puisqu'elle n'implemente aucune 
logique particuliere ni ne passe quoi que ce soit a sa vue correspondante. 

Implementation de la methode executeWaitO dans le fichier apps/frontend/ 
modules/affiliate/actions/actions.class.php 

public function executeWai t(sfWebRequest Srequest) 

{ 

} 



Le partenaire ne peut choisir son propre jeton ni ne peut activer son 
compte immediatement. Pour remplir ce besoin fonctionnel, il est neces- 
saire de personnaliser le formulaire JobeetAffiliateForm. 

Configuration du formulaire d'inscription dans le fichier lib/form/doctrine/ 
JobeetAffiliateForm.class.php 

class JobeetAffiliateForm extends BaseJobeetAffiliateForm 
{ 

public function configure() 
{ 

unset ($this[' is active'] , $this[ ' token' ] , 
$thi s [ ' created at ' ] , $thi s [ ' updated at ' ] ) ; 

$thi s->wi dgetSchema [ ' j obeet categor i es 1 i st ' ] 

->setOption( ' expanded ' , true); 
$thi s->wi dgetSchema [ ' j obeet categor i es 1 i st ' ] 

->setLabel ( ' Categor i es ' ) ; 

$thi s->val i datorSchema[ 1 jobeet_categori es_l i st ' ] 
->setOption(' requi red' , true); 

$this->widgetSchema['url ']->setl_abel ('Your website URL'); 
$this->widgetSchema['url ']->setAttribute('size' , 50) ; 

$this->widgetSchema['email ']->setAttribute('size' , 50) ; 

$this->va"lidatorSchema['email '] = new 
sfValidatorEmail (arrayC requi red' => true)); 

} 

} 

Le framework de formulaires supporte les relations many-to-many avec 
n'importe quelle colonne d'une table. Par defaut, ce type de relation est 
rendu possible a l'aide d'une liste deroulante multiple grace au widget 
sfWidgetFormChoice. Le chapitre 10 a d'ailleurs montre comment le 
rendu HTML final d'un widget sfWidgetFormChoice peut etre modifie 
au moyen de l'option de configuration expanded. 

De plus, comme les adresses e-mails et les URLs ont tendance a etre 
plus longues que la taille par defaut du champ i nput genere, les attributs 
HTML a appliquer par defaut peuvent etre parametres grace a la 
methode setAttributeQ du widget. 




Recent viewed jobs: 



BECOME AN AFFILIATE 



Your website URL 

Email 

Categories 



E Design 

□ Programming 

□ Manager 

0 Administrator 



Submit 



Figure 15-2 Rendu final du formulaire de creation de compte a I'API de Jobeet 



Tester fonctionnellement le formulaire 

La derniere etape consiste comme toujours a ecrire quelques tests fonc- 
tionnels pour s'assurer que la page se comporte correctement. Les tests 
autogeneres du module af f i 1 i ate sont a remplacer par la suite de tests 
fonctionnels ci-apres. 

Scenarios de tests fonctionnels du module affiliate dans le fichier test/functional/ 
frontend/affiliateActionsTest.php 

include(di rname( FILE ) . '/■ ■/■ ./bootstrap/functional .php') ; 

$browser = new JobeetTestFunctional (new sfBrowserO) ; 
$browser->1oadData() ; 

$browser-> 

info('l - An affiliate can create an account')-> 
get ( ' /af f i 1 i ate/new ' ) -> 

cl ick( 'Submit' , arrayC jobeet_affiliate' => array( 

'url' => 'http://www.example.com/', 

'email' => 'foo@example.com', 

' jobeet_categories_list' => 

array (Doctri ne : : getTabl e ( ' JobeetCategory ' ) 
->f i ndOneBySl ug( ' programmi ng ' ) ->getld()) , 

)))-> 

i sRedi rected()-> 
fol lowRedi rect()-> 
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with('response')->checkElement('#content hi', 'Your affiliate 
account has been created' )-> 

info('2 - An affiliate must at least select one category')-> 

get ( ' /af f i 1 i ate/new ' ) -> 

cl ick(' Submit ' , array( ' jobeet_aff i 1 i ate ' => array( 
'url' => 'http://www.example.com/', 
'email' => 'foo@example.com', 

)))-> 

wi th( ' form ' ) ->i sError ( ' jobeet categories 1 i st ' ) 



Developper I' interface (('administration des 
affilies 

Le service web est maintenant actif et les developpeurs peuvent s'inscrire a 
l'API. Or, rinscription a l'API de Jobeet necessite une activation manuelle 
par l'administrateur du site. II convient done de developper une interface 
d'administration propice a la gestion des affilies dans l'application bac- 
kend. Cette derniere permettra a l'administrateur d'activer, de desactiver 
ou bien encore de supprimer un compte developpeur. 

Generer le module d'administration affiliate 

La premiere etape de conception de cette interface d'administration 
consiste a generer le squelette fonctionnel du module de gestion des affi- 
lies. Bien evidemment, il s'agit de ne pas reinventer la roue et de 
s'appuyer a nouveau sur le generateur de backoffice de Symfony. 

$ php symfony doctri ne : generate-admi n backend JobeetAff i 1 i ate - 
-modul e=af f i 1 i ate 

Afin de faciliter l'acces a ce module aux administrateurs, le menu principal 
de navigation doit accueillir un nouveau lien. Ce dernier est defini dans le 
layout de l'application comme le montre l'exemple de code suivant. 

Contenu du fichier apps/backend/templates/layout.php 

<li> 

<a href="<?php echo url for('@jobeet affiliate') ?>"> 
Affiliates - <strongx?php echo 
Doctri ne : : getTabl e( ' JobeetAff i 1 i ate ' ) ->countToBeActi vated() 

?></strong> 

</a> 
</li> 



Ce nouveau lien fait appel a une nouvelle methode 
countToBeActivatedO de l'objet JobeetAffi 1 i ateTabl e qui se charge de 
retourner le nombre de comptes affilies en attente de validation. 
L'implementation de cette methode est decrite dans le code ci-apres. 

Implementation de la methode countToBeActivatedO dans la classe 
JobeetAffiliateTable du fichier lib/model/doctrine/JobeetAffiliateTable.class.php 

class JobeetAffiliateTable extends Doctri ne_Tabl e 
{ 

public function countToBeActivatedO 
{ 

$q = $this->createQuery('a')->where('a. is active = ?', 0); 
return $q->count(); 

} 

// ... 

} 



Parametrer le module affiliate 

Les seules veritables actions necessaires dans ce module d' administration 
correspondent a l'activation ou la desactivation des comptes. De ce fait, la 
vue list peut etre simplified grace a la configuration suivante. Elle surcharge 
les parametres par defaut de la configuration actuelle, et lui ajoute deux 
liens supplementaires pour activer ou desactiver un compte partenaire. 

Configuration du module de gestion des partenaires dans le fichier apps/backend/ 
modules/affiliate/config/generator.yml 

config: 
fields: 

is_active: { label: Active? } 
list: 

title: Affiliate Management 
display: [is_active, url, email, token] 
sort: [is_active] 
object actions: 

activate: 

deactivate: ~ 
batch actions: 

activate: 

deactivate: ~ 
actions: {} 
filter: 

display: [url, email, is_active] 



Implementer les nouvelles fonctionnalites d'administration 

Afin de rendre les administrateurs plus productifs et plus efficaces dans 
leurs taches de gestion de l'application, il semble judicieux de changer les 
filtres par defaut pour n'afficher que les comptes affilies en attente de 
validation. Cette operation est tres simple a mettre en oeuvre puisqu'il 
s'agit de redefinir la methode par defaut getFilterDefaultsO de la 
classe autogeneree affiliateGeneratorConfiguration. 

Redefinition de la methode getFilterDefaults du fichier apps/backend/modules/ 
affiliate/lib/affiliateGeneratorConfiguration. class. php 

class affiliateGeneratorConfiguration extends 

BaseAf f i 1 i ateCene ratorConf i gu rati on 

{ 

public function getFilterDefaultsO 

{ 

return arrayC is active' => '0'); 

} 

} 

II ne reste finalement plus qua implementer le code relatif aux actions 
d'activation et de deactivation de comptes developpeur. La vue list 
declare ces actions aussi bien de maniere unitaire (sur chaque objet) que 
sur un ensemble d'enregistrements selectionnes dans le tableau. Le code 
ci-dessous donne l'integralite des nouvelles methodes implementees 
dans la classe d'actions du module af f i 1 i ate. 

Implementation des actions d'activation et de deactivation de comptes partenaires 
dans le fichier apps/backend/modules/affiliate/actions/actions.class.php 

class affiliateActions extends autoAffiliateActions 
{ 

public function executeLi stActi vate() 
{ 

$this->getRoute()->getObject()->activate() ; 

$this->redi rect('@jobeet_affiliate') ; 

} 

public function executeListDeactivateO 
{ 

$this->getRoute()->getObject()->deactivate() ; 

$this->redi rect('@jobeet_affiliate') ; 

} 

public function executeBatchActi vate(sfWebRequest Srequest) 
{ 

$q = Doctri ne_Query : : createO 
->f rom( ' JobeetAff i 1 i ate a') 

->whereln( ' a. i d ' , $request->getParameter( 1 ids')); 



$affiliates = $q->execute() ; 

foreach ($af filiates as $affiliate) 
{ 

$af f il iate->activate() ; 

} 

$thi s->redi rect ( ' @jobeet_af f i 1 i ate ' ) ; 

} 

public function executeBatchDeacti vate(sfWebRequest $request) 
{ 

$q = Doctrine_Query: :create() 
->from(' JobeetAffiliate a') 

->whereln('a.id' , $request->getParameter('ids')) ; 

$affiliates = $q->execute() ; 

foreach (Saffiliates as Saffiliate) 
{ 

$af f il iate->deactivate() ; 

} 

$thi s->redi rect ( ' @jobeet_af f i 1 i ate ' ) ; 

} 

} 

Certains passages de ce code sont presentes en exergue et montrent l'uti- 
lisation des methodes activate () et deactivate () de l'objet 
JobeetAffiliate qui respectivement activent et desactivent le compte 
affilie. Ces deux nouvelles methodes n' existent pas encore dans le projet 
et doivent etre implementees afin de rendre l'interface de gestion entie- 
rement fonctionnelle. 

Implementation des methods activate() et deactivate() de la classe JobeetAffiliate 
dans le fichier lib/model/doctrine/JobeetAffiliate.class.php 

! class JobeetAffiliate extends BaseJobeetAffi 1 i ate 
{ 

public function activate() 
{ 

$this->setIsActive(true) ; 
return $this->save() ; 

} 



public function deactivated) 
{ 

$this->setIsActive(fal se) ; 



return $this->save() ; 



} 

// 
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Figure 15-3 Rendu final de I'interface d'administration des comptes affilies 

C'est tout pour ce nouveau module. En seulement quelques minutes, 
l'application Jobeet dispose d'un module d'administration pour gerer les 
comptes affilies qui seront ainsi capables de consommer le service web 
mis a leur disposition. Bien que ce module soit completement fonc- 
tionnel, il n'en demeure pas moins qu'il lui manque une fonctionnalite 
primordiale lors de l'activation d'un compte affilie : la notification par e- 
mail. En effet, le systeme n'envoie pour l'instant aucune notification a 
l'utilisateur pour l'informer que son compte a ete valide. 

La section suivante cloture ce chapitre en expliquant pas a pas comment 
integrer un envoi d'e-mail tres simple a l'aide du composant Zend_Mail 
du Zend Framework. 
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Envoyer des e-mails avec Zend Mail 

Lorsqu'un administrateur active le compte d'un affilie, un e-mail devrait 
automatiquement lui etre adresse. Celui-ci lui confirmerait son inscrip- 
tion en lui attribuant son jeton unique afin qu'il puisse consommer le 
service web. Le langage PHP dispose d'un grand nombre d'excellentes 
librairies d'envoi d'e-mails comme SwitfMailer, Zend_Mail ou bien 
encore ezcMail. 

Le chapitre suivant aura recours a des composants du Zend Framework 
pour faciliter la mise en place d'un outil de recherche. C'est en effet dans 
le but de conserver une certaine coherence tout au long du projet que 
seront utilises ici les composants Zend_Mail et Zend_Search du Zend 
Framework. 

Installer et configurer le framework Zend 

La librairie ZencLMai 1 est un composant a part entiere du framework 
Zend. Pour repondre aux besoins technologiques de ce chapitre et des 
suivants, il n'est pas utile d'installer l'integralite du framework Zend. 
Seuls quelques composants de celui-ci ont leur utilite pour le projet. 
Heureusement, la plupart des paquets du Zend Framework sont suffi- 
samment decouples, autonomes et independants les uns des autres pour 
pouvoir etre recuperes individuellement. 

La premiere etape consiste done a recreer la structure allegee du Zend 
Framework en commencant par creer un repertoire Zend dans le reper- 
toire lib/vendor/ du projet. Puis les dossiers et fichiers suivants du 
Zend Framework doivent etre copies dans ce nouveau repertoire : 

• Exception . php 

• Loader/ 

• Loader. php 

• Mail/ 

• Mail. php 

• Mime/ 

• Mime. php 

• Search/ 

Le repertoire Loader/ contient le composant de chargement des classes 
du Zend Framework a la demande. Les paquets Mai 1/ et Mime/ contien- 
nent les classes necessaires a l'envoi d'e-mails avec ou sans pieces jointes 
tandis que le composant Search/ aura la charge d'indexer et de retrouver 
du contenu pour le moteur de recherche de Jobeet. 



Maintenant que les composants du Zend Framework sont integres au 
projet, il ne reste plus qua indiquer a Symfony comment il doit charger 
les classes. C'est en realite le composant ZencLLoader qui a la responsabi- 
lite de charger dynamiquement les classes du framework Zend. Le code 
ci-dessous presente de quelle maniere ce composant doit etre initialise 
depuis la classe de configuration globale du projet. 

Implementation de la methode registerZendO dans la classe ProjectConfiguration du 
fichier config/ProjectConfiguration.class.php 

class ProjectConfiguration extends sfProjectConfiguration 
{ 

static protected SzendLoaded = false; 

static public function registerZendO 
{ 

if (self : : SzendLoaded) 
{ 

return; 

} 

set i ncl ude path (sf Conf i g : : get ( ' sf 1 i b di r ' ) 

. ' /vendor ' . PATH_SEPARATOR . get i ncl ude path () ) ; 

require once sfConfig: :get('sf lib dir') 
. '/vendor/Zend/Loader .php' ; 

Zend Loader : : registerAutoload() ; 

sel f: : SzendLoaded = true; 

} 

// ... 

} 

La classe ProjectConfiguration est dotee a present d'un nouvel attribut 
booleen, protege et statique qui determine si les classes du Zend Fra- 
mework ont ete chargees automatiquement ou pas. La methode 
registerZendO, quant a elle, a pour mission d'ajouter le repertoire lib/ 
vendor a la liste des chemins dans lesquels PHP tentera de trouver et 
d'importer les classes demandees, mais aussi et surtout de charger et 
d'initialiser le chargement automatique de classes du framework Zend. 

Implementer 1'envoi d'un e-mail a l'activation du 
compte de I affilie 

La derniere etape consiste a implementer la logique metier de 1'envoi de 
l'e-mail a destination de l'affilie lors de l'activation de son compte par un 
administrateur. Lenvoi du courrier electronique est laisse a la charge du 
controleur, c'est pour cette raison qu'il trouve naturellement sa place 
dans le corps de la methode executeListActivate(). 



Implementation de I'envoi d'e-mails dans la methode executeListActivateO du fichier 
apps/backend/modules/affiliate/actions/actions.class.php 

class affiliateActions extends autoAffiliateActions 
{ 

public function executeListActivateO 
{ 

Saffiliate = $thi s->getRoute()->getObject() ; 
$af f i 1 i ate->acti vate () ; 

// send an email to the affiliate 
ProjectConfiguration : : registerZend() ; 
$mai1 = new Zend Mail (); 
$mai1 ->setBodyText(<«EOF 
Your Jobeet affiliate account has been activated. 

Your token is {$aff il iate->getToken()} . 

The Jobeet Bot. 
EOF 

); 

$mai"l->setFrom(' jobeet@examp1e.com' , 'Jobeet Bot'); 
$mail->addTo($affil iate->getEmail ()) ; 
$mail->setSubject(' Jobeet affiliate token'); 
$mail ->send() ; 

$thi s->redi rect ( ' @jobeet_af f i 1 i ate ' ) ; 

} 

// ... 

} 

Le principe de fonctionnement du code mis en avant est simple. L'appel 
a la methode statique regi sterZendO permet d'importer et d'initialiser 
la classe de chargement automatique des composants du framework 
Zend. Une fois cette operation accomplie, un nouvel objet Zend_Mai 1 est 
instancie afin de preparer l'e-mail qui est finalement envoye a son desti- 
nataire a l'appel de la methode send(). Pour que I'envoi de l'e-mail fonc- 
tionne correctement, l'adresse e-mail fictive jobeet@example.com doit 
etre remplacee par une adresse reelle. 

Bien sur, il ne s'agit ici que d'un exemple minimaliste de generation d'e- 
mail avec cette librairie. Le composant Zend_Mail recele bien d'autres 
atouts comme I'envoi d'e-mails au format HTML, le support des pieces 
jointes, la manipulation des messages via les protocoles SMTP et POP3. . . 
La documentation de Zend_Mai 1 ainsi que de nombreux exemples de mise 
en pratique sont presentes sur le site officiel du framework Zend. 



En resume 



Grace a 1'architecture REST de Symfony, Implementation de services web 
dans les projets se voit grandement simplifies Bien que le code ecrit dans ce 
chapitre corresponde uniquement a un service web accessible en lecture, 
vous disposez a present de toutes les connaissances suffisantes pour deve- 
lopper votre propre service web interrogeable en lecture et en ecriture. 

L'implementation du formulaire de creation d'un compte affilie dans les 
applications frontend et backend a ete particulierement facilitee dans la 
mesure ou vous etes maintenant familier avec tout le processus d'ajout de 
nouvelles fonctionnalites a un projet Symfony. 

Le chapitre suivant implemente la toute derniere fonctionnalite majeure 
du site Internet de Jobeet - le moteur de recherche - developpee a l'aide 
du composant Zend_Search_Lucene du framework Zend... 
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Deployer 
un moteur de recherche 



MOTS-CLES 



L'une des fonctionnalites les plus difficiles a mettre en oeuvre 
dans une application web dynamique est le moteur de 
recherche, dans la mesure ou il doit generalement etre capable 
de rechercher dans l'integralite du contenu. Quelques outils 
d'indexation de contenu open source existent dont le plus 
connu, Lucene, dispose d'un composant ecrit en PHP pour le 
framework Zend. C'est celui-ci qui sera implements pour 
Jobeet dans la suite de ce chapitre. 



► Indexation avec 
Zend_Search_Lucene 

► Transactions SQL avec Doctrine 

► Tests unitaires 

► Taches automatisees 



L'application Jobeet dispose de tout l'equipement necessaire pour assurer 
la creation de nouveaux contenus, ainsi que la diffusion de ces derniers a 
travers Internet a l'aide des flux ATOM et de son service web. Nean- 
moins, il manque une fonctionnalite essentielle au site Internet : un 
moteur de recherche. Ce moteur de recherche doit en effet permettre aux 
utilisateurs de faciliter leur recherche d'offres d'emploi en saisissant des 
mots-cles pertinents. L'objectif de ce chapitre est de mettre en place pas a 
pas un moteur de recherche base sur la solution d'indexation Lucene. 

Decouverte de la librairie 
Zend_Search_Lucene 

Rappels historiques au sujet de Symfony 

Avant de plonger tete la premiere dans le developpement du moteur de 
recherche, un bref rappel de l'historique de Symfony semble opportun. 
L'equipe du projet Symfony s'efforce depuis toujours de proner les 
meilleures pratiques de developpement, telles que les tests et le refacto- 
ring du code, et par la meme occasion de les mettre en oeuvre au sein du 
framework lui-meme. L'une des principales devises du framework est 
par exemple de ne pas reinventer la roue {do not reinvent the wheel), et 
c'est pour cette raison que Symfony est ne il y a quatre ans en embar- 
quant deux projets Open Source matures : Mojavi et Propel. 

Aujourd'hui encore, lorsqu'il y a un nouveau probleme a resoudre, 
l'equipe de Symfony se pose toujours la question de savoir s'il existe deja 
ou non une quelconque implementation recuperable qui repond au 
besoin, avant de coder quoique ce soit depuis zero. 

Presentation de Zend Lucene 

L'objectif de ce chapitre est d'ajouter un moteur de recherche a l'applica- 
tion Jobeet, et heureusement le framework Zend fournit une excellente 
librairie nommee Zend_Search_Lucene, qui est un portage en PHP du 
celebre projet Open Source Java Lucene. Au lieu de creer un nouveau 
moteur de recherche pour Jobeet, ce qui est une tache particulierement 
complexe et chronophage, il sera plus pertinent de reutiliser le compo- 
sant Zend Lucene. La documentation de Zend_Search_Lucene pre- 
sente sur le site officiel du framework Zend decrit cette librairie de la 
maniere suivante : 
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Zend Lucene est un moteur de recherche de contenus principalement 
textuels ecrit entierement en PHP 5. Comme il sauvegarde son index sur 
le systeme de fichiers local et qu'il ne requiert aucun serveur de base de 
donnees, il peut ajouter des capacites de recherche a la plupart des sites 
Internet concus en PHP 5. Zend_Search_Lucene supporte les fonction- 
nalites suivantes : 

• recherche triee par pertinence : les meilleurs resultats sortent en 
premier ; 

• differents types de requete pour interroger l'index : chaines de carac- 
teres, booleen, asterisque, proximite, intervalles et bien d'autres ; 

• recherche sur un champ specifique (par exemple : titre, auteur, con- 
tenus...). 

Ce chapitre n'est pas un tutoriel d'utilisation de la librairie Zend Lucene, 

mais seulement un exemple d'integration de celle-ci dans Implication ► http://framework.zend.com/ 

Jobeet, ou plus generalement, un exemple d'integration de composants 

tierces parties a l'interieur d'un projet Symfony. Pour en savoir plus au 

sujet de cette technologie, la documentation de Zend Lucene est dispo- 

nible sur le site officiel du Zend Framework. La librairie Zend Lucene a 

deja ete installee dans Jobeet au chapitre precedent. Elle se trouve dans 

le repertoire Search/ du framework Zend. 



Indexer le contenu de Jobeet 

Le moteur de recherche de Jobeet doit etre capable de retourner toutes les 
offres qui correspondent aux mots-cles saisis par l'utilisateur. Cependant, 
avant de pouvoir rechercher une quelconque information, il est necessaire 
qu'un index des annonces soit construit en amont. Ce dernier sera stocke 
sur le systeme de fichier local dans le repertoire data/ du projet. 

Creer et recuperer le fichier de l'index 

Zend Lucene fournit deux methodes pour retrouver un index selon qu'il 
existe deja ou pas. Dans un premier temps, il convient de creer une 
methode « helper » dans la classe JobeetJobTable qui retourne un index 
existant ou bien en genere un nouveau a la volee. 

Declaration des methodes de creation et de recuperation de l'index des offres 
d'emploi dans le fichier lib/model/doctrine/JobeeUobTable.class.php 

static public function getLucenelndexO 
{ 

ProjectConfiguration: : regi sterZendQ ; 
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if (file_exists($index = self : :getLuceneIndexFile())) 
{ 

return Zend_Search_Lucene : :open($index) ; 

} 

else 
{ 

return Zend_Search_Lucene : : create($i ndex) ; 

} 

} 

static public function getl_uceneIndexFile() 
{ 

return sfConfig: : get( ' sf_data_di r') . '/ 
job. ' .sfConfig: : get( 1 sf_envi ronment') . ' .index' ; 
} 

Mettre a jour I'index a la serialisation d'une offre 

Chaque fois qu'une offre est creee, editee ou bien supprimee, I'index de 
celle-ci doit etre mis a jour afin de rester coherent. II est de surcroit pri- 
mordial de ne pas indexer les offres expirees ou non publiees. Le 
meilleur endroit pour regenerer I'index a chaque fois qu'une offre est 
serialisee en base de donnees est bien evidemment la methode save() de 
l'objet. Cette derniere se redefinie de la maniere suivante : 

Redefinition de la methode save() de l'objet JobeetJob dans le fichier lib/model/ 
doctrine/JobeetJob.class.php 

public function save(Doctrine_Connection Sconn = null) 

{ 

// ... 

$ret = parent: :save($conn) ; 
$thi s->updateLuceneIndex() ; 

return $ret; 

} 

La nouvelle methode updateLucenelndexO de cette meme classe a pour 
role de generer I'index Lucene de cette offre au moment ou elle est seria- 
lisee dans la base de donnees. Le code ci-dessous illustre toute l'imple- 
mentation de cette methode. 

Implementation de la methode updateLucenelndexO dans le fichier lib/model/ 
doctrine/JobeetJob.class.php 

i public function updateLucenelndexO 
{ 

$index = $this->getTable()->getLuceneIndex() ; 
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// remove an existing entry -o 
if (Shit = $index->find('pk: * . $this->getld())) =j 

i ~ 1 

$index->delete($hit->id) ; = 



// don't index expired and non-activated jobs 

if ($this->isExpi red() || ! $thi s->getIsActivated()) 

{ 

return ; 

} 

$doc = new Zend_Search_Lucene_Document() ; 

// store job primary key URL to identify it in the search 
results 

$doc->addFi el d(Zend_Search_Lucene_Fi el d : :UnIndexed('pk' , 
$this->getld())) ; 

// index job fields 

$doc->addFi el d(Zend_Search_Lucene_Fi el d : : UnStored ( ' posi ti on ' , 
$this->getPosition() , 'utf-8')) ; 

$doc->addFi el d(Zend_Search_Lucene„Fi el d : : UnStored ('company' , 
$this->getCompany() , 'utf-8')); 

$doc->addFi el d (Zend_Search_Lucene_Fi eld:: UnStored ( ' 1 ocati on ' , 
$this->getLocation() , 'utf-8')); 

$doc- 

>addField(Zend_Search_Lucene_Field: :UnStored('description' , 
$this->getDescription() , 'utf-8')) ; 

// add job to the index 
$i ndex->addDocument($doc) ; 
$i ndex->commi t() ; 



La creation de l'index se deroule en trois etapes successives : 

1 la premiere consiste a supprimer l'index existant de l'offre si ce der- 
nier existe deja car Zend Lucene est incapable de mettre a jour un 
index existant ; 

2 puis le code teste si l'offre en cours est expiree ou bien si elle n'est pas 
encore publiee. Si c'est le cas, il est aucunement necessaire d'indexer 
les donnees afin de ne pas risquer de les ressortir lors d'une future 
recherche ; 

3 ensuite, un nouvel objet Zend_Search_Lucene_Document est cree. La 
cle primaire de l'offre est ajoutee a l'index mais n'est pas indexee afin 
quelle serve de reference de l'offre pour plus tard au moment de la 
recherche. En revanche, les valeurs des champs position, company, 
location et description de l'objet sont indexees mais ne sont pas 
stockees dans l'index : ce seront les objets reels qui seront utilises 
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pour afficher les resultats. Pour finir, le document est ajoute a l'index 
et ce dernier est valide a l'appel de la methode commit (). 

Securiser la serialisation d'unc offre a I'aide d'une 
transaction Doctrine 

Que se passe-t-il si l'indexation d'une offre echoue ou bien si celle-ci n'est 
pas correctement sauvegardee dans la base de donnees ? Doctrine comme 
Zend Lucene lancent une erreur si ce genre de cas venait a se produire. 
Cependant, dans certaines circonstances, l'offre peut avoir ete correcte- 
ment sauvegardee en base de donnees bien que son index correspondant 
n'ait pas ete recree. Afin d'eviter cela, la meilleure solution est d'encapsuler 
les deux procedures de mise a jour de l'objet a l'interieur d'une transaction, 
et de l'annuler (« rollback ») en cas d'interception d'une exception. La 
transaction permet ainsi de garantir l'integrite de l'objet. En effet, si une 
seule manoeuvre echoue, c'est tout le processus de mis a jour de l'objet qui 
est interrompu et reinitialise a son etat precedent. 

Implementation d'une transaction Doctrine pour assurer la coherence entre l'index et 
la base de donnees dans le fichier lib/model/doctrine/JobeetJob.class.php 

public function save(Doctn'ne_Connection $conn = null) 

{ 

// ... 

$conn = $conn ? $conn : $this->getTab1e()->getConnection() ; 

$conn->beginTransaction() ; 

try 

{ 

$ret = parent: :save($conn) ; 
$thi s->updateLuceneIndex() ; 
$conn->commitO ; 
return $ret; 

} 

catch (Exception $e) 
{ 

$conn->rol 1 Back() ; 
throw $e; 

} 

} 



Effacer l'index lors de la suppression d'unc offre 



Lorsqu'une offre est supprimee du site Internet (manuellement ou via la 
tache automatique de nettoyage des offres perimees), son index doit lui 
aussi etre retire du systeme de fichier afin de garantir la coherence des 
informations de Jobeet. Pour automatiser cette operation, la maniere de 
proceder qui semble la plus pertinente est bien evidemment de sur- 
charger rimplementation de la methode deleteO de la classe DobeetJob 
comme le montre le code ci-dessous. 

Redefinition de la methode deleteO des objets JobeetJob dans la classe lib/model/ 
doctrine/JobeeUob.class.php 

public function delete(Doctrine_Connection $conn = null) 
{ 

$index = $this->getTable()->getLuceneIndex() ; 

if ($hit = $index->find('pk: ' . $this->getld())) 
{ 

$index->delete($hit->id) ; 

} 

return parent: : del ete(Sconn) ; 

} 

Manipuler l'index des offres d'emploi 
Regenerer tout l'index des offres d'emploi 

Maintenant que la generation et la suppression de l'index est en place, il ne 
reste plus qua recharger les donnees initiales de Jobeet afin de reconstruire 
l'index de chaque objet. Pour ce faire, il suffit d'executer la tache automatique 
doct ri ne : data- 1 oad utilisee a plusieurs reprises au cours de cet ouvrage. 

j $ php symfony doctrine:data-load --env=dev 

La commande est executee avec l'option --env=dev dans la mesure ou 
l'index est dependant de l'environnement et que l'environnement par 
defaut de la ligne de commande est cl i . 

Implementer la recherche d'informations pour Jobeet 

La prochaine etape consiste a mettre en place la route, la logique metier 
et les vues qui rendent possible la recherche d'offres d'emploi a l'utilisa- 
teur. Limplementation d'une telle fonctionnalite n'est qu'une question 
de quelques minutes. Pour commencer, il faut bien evidemment declarer 
une nouvelle route dans le fichier de configuration routing. yml de 
l'application frontend. 



Environnements Unix 
Acces en ecriture sur l'index 

Les utilisateurs de systemes d'exploitation bases sur 
Unix doivent s'assurer que le fichier de l'index est 
accessible en ecriture a la fois pour l'environnement 
d'execution en ligne de commande et pour celui 
pour le web. II convient done de changer les droits 
du repertoire data/ et de verifier que I'utilisateur 
du serveur web et de la ligne de commande ont 
tous deux acces a ce repertoire en ecriture. 



Configuration PHP Support des fichiers ZIP 

Des avertissements PHP au niveau de la classe 
ZipArchive peuvent etre leves, ce qui signifie 
alors que I'extension zi p n'est pas compilee et 
installee avec PHP. Ceci est un bogue connu de la 
classe Zend_Loader du framework Zend. 
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Ajout de la route job_search au fichier apps/frontend/config/routing.yml 

job_search : 

url : /search 

param: { module: job, action: search } 

A la suite de cela, il convient d'implementer le controleur search du 
module job comme le montre le code ci-dessous. 

Implementation de la methode executeSearch() dans le fichier apps/frontend/ 
modules/job/actions/actions.class.php 

class jobActions extends sf Actions 
{ 

public function executeSearch(sfWebRequest $request) 
{ 

if (!$query = $request->getParameterC'query')) 
{ 

return $this->forward( ' job' , 'index'); 

} 

$this->jobs = Doctrine: :getTab1e('DobeetJob') 
->getForLuceneQuery($query) ; 

} 

// ... 

} 

Le corps de la methode executeSearchO est tres basique puisqu'il ne 
realise que deux actions principales. Tout d'abord, une condition verifie 
si l'objet correspondant a la requete contient un parametre query et 
stocke sa valeur dans la variable $query. Si ce parametre n'existe pas ou 
bien si sa valeur est nulle, alors la requete est transmise a Taction i ndex 
du meme module ; dans le cas contraire, c'est la nouvelle methode 
getForLuceneQueryO qui prend en charge la recuperation des offres cor- 
respondantes aux mots-cles passes en parametre. L'implementation de 
cette derniere se trouve juste apres. 

Implementation de la methode getForLucenelndex() dans le fichier lib/model/ 
doctrine/JobeetJobTable.class.php 

public function getForLuceneQuery(Squery) 
{ 

$hits = $this->getLuceneIndex()->find($query) ; 

$pks = array(); 
foreach ($hits as $hit) 
{ 

$pks[] = $hit->pk; 

} 



if (emptyCSpks)) 
{ 

return arrayO; 

} 

$q = $this->createQuery(' j ') 
->whereln(' j .id' , $pks) 

->limit(20) ; 

return $this->addActiveJobsQuery($q)->execute() ; 

} 

La comprehension du code de cette methode ne pose pas de reelle diffi- 
culte. La premiere instruction fait appel a la methode find() de l'objet 
Zend_Search_Lucene representant l'index du site Internet. La methode 
find() retourne une collection d'objets qui repondent aux mots-cles de 
l'utilisateur dans l'index. Puis, la structure conditionnelle foreachO par- 
court cette collection afin d'en recuperer les valeurs des cles primaires des 
offres d'emploi enregistrees dans l'index. Une requete Doctrine est enfin 
construite et executee dans le but de retourner une collection des vingt 
premiers objets JobeetJob valides qui satisfont la recherche de l'utilisateur. 

Quant au template searchSuccess.php, il ne tient qu'en quelques lignes 
de PHP grace a tous les remaniements et factorisations de code realises 
jusqu'a present. 

Contenu du template apps/frontend/modules/job/templates/searchSuccess.php 

<?php use_styiesheet(' jobs. ess') ?> 
<div id="jobs"> 

<?php include partial ('job/list' , arrayC jobs' => $jobs)) ?> 

</di v> 

Enfin, il ne reste plus qua ajouter le moteur de recherche sur chaque 
page du site afin que tout soit definitivement operationnel. Pour ce faire, 
il suffit d'ajouter le code HTML d'un formulaire basique dans le layout 
de l'application f rontend comme le montre le code ci-apres. 

Integration du moteur de recherche dans le fichier apps/frontend/templates/ 
layout, php 

<h2>Ask for a job</h2> 

<form action="<?php echo url for('@job search') ?>" 

method="get"> 

<input type="text" name="query" value="<?php echo 
$sf request->getParameter(' query') ?>" id="search keywords" /> 

<input type="submit" val ue="search" /> 

<div cl ass="hel p"> 

Enter some keywords (city, country, position, ...) 

</di v> 
</form> 



Remarque Zend Lucene : requetes 
supportees pour interroger l'index 

La librairie Zend Lucene definit un langage de 
requete tres riche qui supporte notamment les 
operations booleennes, joker, de proximite et bien 
d'autres encore. L'ensemble de ces fonctionnalites 
ainsi que I'utilisation de I'API sont largement 
documented dans le manuel d'utilisation de Zend 
Lucene sur le site officiel du framework Zend a 
I'adresse http://framework.zend.com/ 
manual/en/zend. search, lucene. html 
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Tester la methode getForLuceneQueryO 
de JobeetJob 

Afin de valider la bonne integration de Zend Lucene dans Jobeet ainsi 
que le fonctionnement general du moteur de recherche, il convient 
d'ecrire quelques series de tests fonctionnels. Mais quels genres de tests 
unitaires est-il possible et judicieux de mettre en ceuvre ? Bien evidem- 
ment, il est inutile de tester la libraire Zend Lucene elle-meme dans la 
mesure ou cela a deja ete realise par l'equipe de developpement du Zend 
Framework. En fait, il s'agit de verifier l'integration de celle-ci au sein de 
la classe JobeetJob. 

L'ideal est done de tester la methode getForLuceneQueryO qui fait le 
pont entre la libraire Zend_Search_Lucene et le moteur de recherche de 
Jobeet. Le code ci-dessous presente les suites de tests unitaires de la 
methode getForLuceneQueryO a ajouter au bas du fichier 
Jobeet JobTest.php en n'oubliant pas de mettre a jour le compteur de 
tests planifies a la valeur 7. 

Integration des tests unitaires du moteur de recherche dans le fichier test/lib/ 
model/JobeetJobTestphp 

$t->comment( ' ->getForLuceneQuery() ' ) ; 

$job = create_job(array('position' => 'foobar', ' i s_acti vated ' 
=> false)); 
$job->save() ; 

$jobs = Doctrine: :getTable(' JobeetJob') 

->getForLuceneQuery( ' position : foobar ' ) ; 
$t->is(count($jobs) , 0, ' : : getForLuceneQueryO does not return 
non activated jobs'); 

$job = create_job(array('position' => 'foobar', ' i s_acti vated ' 
=> true)) ; 
$job->save() ; 

$jobs = Doctrine: :getTable(' JobeetJob') 

->getForLuceneQuery( ' position : foobar ' ) ; 
$t->is(count($jobs) , 1, ' : : getForLuceneQueryO returns jobs 
matching the criteria'); 

$t->is($jobs[0]->getld() , $job->getId() , ' : : getForLuceneQueryO 
returns jobs matching the criteria'); 

$job->deiete() ; 

$jobs = Doctrine: :getTable(' JobeetJob') 

->getForLuceneQuery( ' position : foobar ' ) ; 
$t->is(count($jobs) , 0, ' : : getForLuceneQueryO does not return 
deleted jobs'); 

Lobjectif de ces trois series de tests unitaires est de controler qu'une 
offre d'emploi non publiee ou bien supprimee n'apparait pas dans les 



resultats de recherche, alors qu'inversement, les offres qui correspondent 
aux criteres de recherche apparaissent dans ces resultats. 

Nettoyer regulierement r index des offres 
perimees 

Avec le temps, il arrive que certaines offres atteignent leur date d'expira- 
tion et ne soient pas renouvelees pour une nouvelle periode de trente 
jours. Leurs informations restent alors conservees dans l'index puisque 
ces offres sont toujours presentes dans la base de donnees. De toute evi- 
dence, il semble pertinent de nettoyer l'index regulierement afin de sup- 
primer toute information relative a une offre perimee. Cela aura pour 
effet immediat de liberer de la place dans l'index, ce qui le rendra plus 
performant par la meme occasion. 

La maniere ideale et efficace pour nettoyer l'index periodiquement est de 
creer et d'executer une commande Symfony a l'aide d'une tache plani- 
fiee. Or, Implication Jobeet dispose depuis le chapitre 11 d'une tache 
automatique de nettoyage des offres perimees de la base de donnees. 
L'objectif est done de profiter de l'existence de cette tache pour l'enrichir 
en lui integrant le processus de mise a jour de l'index. 

Implementation du nettoyage de l'index dans la tache JobeetJobCleanup du fichier 
lib/task/JobeetCleanupTask.class.php 

protected function execute($arguments = arrayO, Soptions = 

arrayO) 

{ 

SdatabaseManager = new sfDatabaseManager($thi s 

^configuration) ; 

// cleanup Lucene index 

$index = Doctrine: :getTab1e(' JobeetJob')->getLuceneIndex() ; 

$q = Doctrine Query: :create() 
->f rom( ' Jobeet Job j') 

->where('j .expires at < ?', date('Y-m-d')) ; 

$jobs = $q->execute() ; 
foreach ($jobs as $job) 
{ 

if ($hit = $index->find('pk: ' . $job->getId())) 
{ 

$hit->delete() ; 

} 

} 



$index->optimize() ; 



$this->logSection('"lucene' , 'Cleaned up and optimized the job 
index') ; 

// Remove stale jobs 
$nb = Doctrine: :getTable(']obeetJob') 
->cleanup($options['days']) ; 

$this->logSection('doctrine' , spri ntf( ' Removed %d stale 
jobs', $nb)); 
} 

Le code mis en avant ici correspond a la logique necessaire pour retirer de 
l'index les informations obsoletes. Pour commencer, la requete Doctrine 
recupere la collection d'objets JobeetJob ayant deja expire. Puis, pour 
chaque offre d'emploi, la methode fi nd() de l'index tente de retrouver les 
informations indexees et referencees a la valeur de la cle primaire de 
l'annonce, et stocke l'objet resultant dans la variable Shit en cas de succes. 
Des lors, l'appel a la methode deleteO sur cette derniere suffit a effacer 
les donnees indexees de 1' offre courante dans l'index. Enfin, la methode 
optimizeO se charge, comme son nom l'indique, d'optimiser tout l'index 
lorsque l'ensemble des donnees obsoletes a ete eradique. 



En resume 



Ce seizieme chapitre a ete l'occasion d'implementer un moteur de 
recherche completement fonctionnel en moins d'une heure. II faut tou- 
jours avoir a l'esprit de verifier s'il existe deja ou non des solutions aux 
problemes que Ton cherche a resoudre sur un nouveau projet. II s'agit 
d'abord de verifier si la solution technique n'est pas deja integree native- 
ment dans le framework. Puis, si ce n'est pas le cas, le bon reflexe a 
adopter consiste a parcourir le depot des plug-ins de Symfony, a l'affut 
d'un eventuel plug-in existant. Enfin, si la solution technique ne se 
trouve pas en ces lieux, il ne faut pas hesiter a aller la chercher dans des 
ressources en ligne comme les bibliotheques Open Source telles que le 
Zend Framework ou les composants ezComponents. 

Le chapitre suivant aborde les notions d'Ajax et de JavaScript non 
intrusif afin d'ameliorer la reactivite du moteur de recherche en mettant 
a jour les resultats en temps reel a chaque fois que l'utilisateur saisit de 
nouvelles lettres sur son clavier dans le formulaire de recherche... 



chapitre 




Dynamiser I'interface 
utilisateur avec Ajax 



MOTS-CLES 



Avec l'arrivee des navigateurs web modernes il y a quelques 
annees, de nombreuses applications web se sont dotees 
d'interfaces riches (RIA) et dynamiques reposant sur 
la technologie JavaScript. Lessor des frameworks JavaScript 
tels que Prototype, jQuery ou MooTools, ont par la meme 
occasion largement participe au developpement de ces 
interfaces et plus parti culierement a l'adoption de lAjax. 

Symfony supporte nativement les requetes HTTP asynchrones 
(Ajax) et en simplifie grandement la gestion. 



► JavaScript, Ajax et jQuery 

► Tests fonctionnels 

► Couche controleur 



BONNE PRATIQUE JavaScript non intrusif 

Une bonne pratique du developpement JavaScript 
consiste a systematiquement externaliser le code 
source dans des fichiers, et ne pas I'inscrire en le 
melangeant au contenu HTML. Cette solution pre- 
sente des avantages certains : en matiere d'orga- 
nisation, il sera plus simple de s'y retrouver. 
Egalement, lorsque le JavaScript ne sera pas 
active sur le poste de I'utilisateur, le code JavaS- 
cript ne sera pas charge inutilement en memoire. 
Certes, cette solution implique une requete HTTP 
supplemental, mais c'est la un moindre mal 
sachant que ce fichier JavaScript externe sera de 



Le chapitre precedent a ete l'occasion d'instaUer un moteur de recherche 
puissant et fonctionnel pour Jobeet a l'aide de la librairie Zend Lucene du 
framework Zend. Lobjectif de ces prochaines pages est d'ameliorer la reacti- 
vite de ce moteur de recherche en tirant partie des avantages d'Ajax afin de 
permettre la recherche en temps reel. II s'agit d'une fonctionnalite que Ton 
retrouve par exemple sur la page d'accueil de Google. 

Le formulaire de recherche est prevu pour fonctionner avec ou sans 
JavaScript active. Pour cette raison, la fonctionnalite de recherche en 
temps reel sera alors implementee grace a du JavaScript non intrusif base 
sur un framework JavaScript. Lutilisation de JavaScript non intrusif 
permet egalement une meilleure separation des metiers cote client entre 
le HTML, la CSS et les comportements JavaScript. 



Choisir un framework JavaScript 

Decouvrir la librairie jQuery 

Au lieu de reinventer la roue et de perdre du temps a gerer les differences 
d'interpretation des moteurs d'execution des navigateurs web, le deve- 
loppement de la recherche en temps reel s'appuiera sur l'usage du fra- 
mework JavaScript jQuery. Le framework Symfony peut bien sur 
fonctionner avec n'importe quelle librairie JavaScript. 

jQuery est un framework JavaScript libre developpe par John Resig, 
developpeur a la fondation Mozilla, et apparu publiquement dans le 
courant du mois de janvier 2006. jQuery apporte une API qui simplifie 
la syntaxe native du langage JavaScript en fournissant une syntaxe fiuide 
et tres verbeuse ainsi que de nombreuses fonctionnalites de base. Parmi 
elles figurent : 

• le support du parcours et de modification du DOM (Document 
Object Model) ; 

• le support des CSS 1, CSS 2 et CSS 3 ainsi qu'une partie de XPath ; 

• la gestion des evenements ; 

• le support de comportements comme le drag and drop, classement, 
redimensionnement... ; 

• l'integration d'effets et d'animations tels que les zooms, fades in, fades 
out... ; 

• la manipulation des feuilles de style en cascade (ajout et suppression 
de classes, d'attributs...) ; 

• le support des requetes asynchrones (composant Ajax) ; 
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• l'integration de plug-ins tierces parties ; 

• la compatibilite entre les differents navigateurs... 

Le projet jQuery a l'avantage de beneficier d'une documentation abon- 
dante et tres claire dotee de nombreux exemples pratiques prets a etre 
mis en ceuvre. D'autre part, cette librairie est supportee par une commu- 
naute toujours croissante de developpeurs qui participent a l'ameliora- 
tion du projet en proposant librement des portions de code, des 
applications completes et fonctionnelles, des retours d'experience, ou 
bien encore de la documentation. II existe egalement une liste de diffu- 
sion extremement active a partir de laquelle les utilisateurs ont la capa- 
cite de prevenir l'equipe de developpement de bogues eventuels. 

Telecharger et installer jQuery 
Recuperer la derniere version stable du projet 

L'installation de jQuery est particulierement facile puisqu'il s'agit de 
telecharger un seul fichier JavaScript contenant tout le code de la 
librairie, puis de le charger dans les pages web a l'aide d'une balise 
<script>. La derniere version du framework jQuery est disponible en 
telechargement libre sur le site officiel du projet a l'adresse http:// 
docs.jquery.eom/DownloadingJQuery#DownloadjQuery. Pour commencer, le 
fichier source . js de la toute derniere version stable de jQuery doit etre 
recupere, puis depose dans le repertoire web/js du projet Symfony. 

Deux versions de la librairie sont disponibles : minifiee et non compressee. 
La version non compressee correspond au code source tel qu'il a ete ecrit 
par John Resig, e'est-a-dire avec les espaces, les indentations, les commen- 
taires, les retours a ligne... Le poids du fichier final est done largement 
optimisable puisqu'il contient majoritairement des caracteres inutiles a son 
interpretation par le navigateur. En revanche, le fichier minifie est le code 
source final apres que tous ces caracteres superfius ont ete supprimes, ren- 
dant alors ce dernier completement illisible par l'humain mais beaucoup 
plus leger et rapide a charger. Etant donne que l'implementation interne 
du code de jQuery ne fait pas l'objet de cet ouvrage, mais surtout quelle 
doit verifier des conditions evidentes de performance, e'est la version 
minifiee de jQuery qui sera utilisee dans ce projet. 

Charger la librairie jQuery sur chaque page du site 

Le moteur de recherche d'offres d'emploi de Jobeet est present sur 
chaque page du site Internet, cela implique que la librairie jQuery soit 
importee sur chacune d'entre elles. Lendroit ideal pour faire appel a ce 
nouveau JavaScript sur chaque page est, bien entendu, le layout puisqu'il 



est partage par toutes les pages du site. L'inclusion du fichier . js se rea- 
lise a l'aide du helper use_javascript() dans la section <head> du layout. 
II faut cependant faire attention a inserer la fonction use_javascri pt() 
avantl'appel au helper inc"lude_javascripts(). 

Chargement de la librairie jQuery dans le fichier apps/frontend/templates/ 
layout.php 

<?php use javascript(' jquery-1.2.6.min. js') ?> 

<?php include_javascn'pts() ?> 
</head> 

II est bien sur possible d'inclure le code source de jQuery directement en 
ecrivant la balise <scri pt> manuellement mais l'utilisation de la fonction 
use_javascri pt() a l'avantage de s'assurer que le fichier JavaScript n'est 
inclus qu'une seule fois. 

ASTUCE Charger les JavaScripts a la fin de la page 

Le navigateur web interprete une page web de haut en bas, c'est-a-dire qu'il charge en 
premier lieu toutes les ressources qui se trouvent dans la section <head> de cette der- 
niere. Les fichiers JavaScript ont le desagreable defaut d'empecher la parallelisation des 
telechargements des ressources lorsque le navigateur est en train de les recuperer. Cela a 
pour effet immediat d'augmenter le temps de chargement de la page en cours et de dimi- 
nuer I'acces a I'information. 

Une bonne pratique consiste done a charger les fichiers JavaScript uniquement lorsque 
toute la page est chargee afin de permettre a I'utilisateur d'acceder directement a I'infor- 
mation sans ralentissement. Pour ce faire, il suffit de deplacer I'appel au helper 
i ncl ude_javascri pts() juste avant la fermeture de la balise </body> du layout. 
Les articles de la zone des developpeurs de Yahoo! expliquent et donnent de nombreuses 
astuces pour vous aider a optimiser les performances d'une application web cote client et 
cote serveur : 

http://developer.yahoo.eom/performance/rules.html#js_bottom 

Decouvrir les comportements JavaScript 
avec jQuery 

Implementer une recherche en temps reel implique d'interroger le ser- 
veur web a chaque fois que I'utilisateur saisit une nouvelle lettre dans la 
boite de recherche. Cette requete au serveur est ensuite suivie par une 
reponse, dans un format donne (HTML, JSON, XML...), et inter- 
ceptee par le navigateur afin de mettre a jour certaines regions de la page 
web sans avoir a en rafraichir l'integralite. 



Intercepter la valeur saisie par l'utilisateur dans le 
moteur de recherche 

Traditionnellement, les comportements JavaScript se definissent et 
s'executent grace aux attributs HTML on* tels que onsubmit, onfocus, 
onblur, onclick... Cependant, cette pratique desormais obsolete a le 
principal defaut d'engendrer des erreurs si le JavaScript nest pas active 
sur le navigateur, mais va egalement a l'encontre du principe de non- 
intrusivite explique plus haut. De plus, elle lie fortement le code JavaS- 
cript au document HTML. Lapproche avec jQuery est differente et plus 
intelligente puisqu'il s'agit d'attacher les comportements aux evenements 
du DOM une fois la page completement chargee. De cette maniere, si le 
support du JavaScript est desactive dans le navigateur, aucun comporte- 
ment ne sera declare, et le formulaire continuera de marcher comme 
avant. C'est le principe du Javascript non-intrusif. 

La premiere etape du developpement de la recherche en temps reel con- 
siste a intercepter la valeur de la boite de saisie a chaque fois que l'utilisa- 
teur tape une nouvelle lettre. Avec jQuery, cela tient en quelques lignes 
seulement grace a son API fluide. 

$ ( ' #search keywords ' ) . keyup (f uncti on (key) 
{ 

if (this. value. length >= 3 | | this. value == '') 
{ 

// do something 

} 

}); 

Cette syntaxe que fournit jQuery permet d'ajouter facilement un com- 
portement a un evenement parti culier, ici key up, a un ou plusieurs objets 
du DOM en specifiant la valeur de son attribut unique i d ou de sa classe 
CSS. Dans le cas present, la chaine #search_keywords indique que Ton 
applique le comportement keyup a l'objet dont 1' attribut id (represente 
par le symbole diese #) porte la valeur search_keywords. La fonction 
speciale $ () de jQuery permet de recuperer un objet ou toute une collec- 
tion d'objets du DOM qui correspondent a 1' expression passee en para- 
metre. Cette fonction est en quelque sorte un equivalent ameliore des 
traditionnelles methodes getElementByldO, getElementByTagName()... 
Enfin, le code de la fonction anonyme du comportement associe a 1' eve- 
nement keyup se charge d'executer toute la logique metier de la 
recherche en temps reel. L'objet this represente ici l'objet DOM recu- 
pere grace a la fonction $(). Dans le cas present, il s'agit du nceud DOM 
de la balise <input/> ; c'est pour cette raison qu'il est possible d'acceder 
directement a la valeur saisie par l'utilisateur grace a thi s . val ue. 



Executer un appel Ajax pour interroger le serveur web 



Chaque fois que l'utilisateur tape sur une touche de son clavier, jQuery 
execute la fonction anonyme definie dans le code ci-dessus a condition 
que la chaine saisie soit composee de plus de 3 caracteres, ou que la 
valeur du champ ait ete reinitialisee. 

Realiser un appel Ajax au serveur consiste simplement a appliquer la 
methode load() sur le noeud DOM dans lequel on souhaite charger la 
reponse renvoyee par le serveur. Grace a jQuery, il n'y a plus besoin de 
declarer soi-meme l'objet XMLHTTPRequest (ou ActiveX dans le cas 
d'Internet Explorer) et de gerer le traitement de la reponse en fonction du 
code HTTP renvoye dans les en-tetes de la reponse. Toutes ces etapes fas- 
tidieuses sontgerees automatiquement par la methode "loadO de jQuery. 

$( '#search_keywords 1 ) . keyup (function (key) 
{ 

if (this. value. length >= 3 | ] this. value == '') 

{ 

SC'tfjobs^.loadC 

$(this) .parents(' form') .attr('action') , { query: 
this. value + '*' } 

); 

} 

}); 

La methode load() accepte trois arguments dont seul le premier est 
obligatoire. Cet argument correspond a l'URL a appeler, et dans le cas 
present, il s'agit de la valeur de l'attribut action de la balise <form> du 
moteur de recherche. Le second argument est un tableau associatif de 
parametres a envoyer au serveur tandis que le troisieme est le nom d'une 
fonction JavaScript a executer lorsque la requete Ajax sera complete et 
que le serveur aura renvoye une reponse. Dans le cadre de Jobeet, ce der- 
nier argument n'est pas necessaire et est done omis. En revanche, la 
methode load() du script ci-dessus accueille un objet anonyme conte- 
nant la propriete query a transmettre au serveur. Cette derniere contient 
la valeur saisie par l'utilisateur, suffixee par le symbole etoile *. 

Recuperer dynamiquement l'URL du formulaire en parcourant l'arbre 
DOM du document apporte de serieux avantages. Le premier est bien 
evidemment qu'il n'est pas necessaire de recopier ou de regenerer soi- 
meme l'URL a l'aide du helper ur"l_for(). D'autre part, cela rend le 
code JavaScript independant de son implementation dans l'application. 
II sera ainsi plus facile de reutiliser ce code dans un autre projet sans 
avoir a le modifier. Enfin, comme l'URL utilisee est finalement la meme 
que celle du moteur de recherche en mode « degrade » (i.e. sans JavaS- 
cript), le developpement cote serveur s'en voit done allege. 



Cacher dynamiquement le bouton d'envoi du formulaire 



Lorsque JavaScript est active sur le navigateur, le bouton d'envoi du for- 
mulaire n'a plus veritablement d'utilite puisque toutes les actions relatives a 
la recherche sont gerees dynamiquement par les comportements JavaS- 
cript. De ce fait, il convient de masquer ce bouton de la page en appelant 
la methode jQyery hide() sur l'objet DOM de ce dernier. La methode 
hi de () modifie les valeurs des proprietes CSS de l'objet afin de le cacher. 

| $('. search input [type="submit"] ') .hide() ; 

Cette instruction montre egalement combien il est aise d'acceder a un ou 
plusieurs objets du DOM en fournissant une expression plus ou moins 
complexe a la fonction $ () . Ici, le bouton d'envoi du formulaire est cible 
par l'expression CSS 3 indiquant qu'il se trouve dans un conteneur 
parent ayant un attribut cl ass dont la valeur est search. 



Informer I'utilisateur de I'execution de la 
requete Ajax 

A chaque fois qu'un appel Ajax est execute, la region de la page a modifier 
n'est pas mise a jour immediatement. Le navigateur doit en effet attendre 
que la reponse du serveur lui revienne avant de mettre a jour le document. 
Le temps d'attente de la reponse est variable en fonction de la complexity 
de Taction executee, de l'engorgement des reseaux, ou bien encore de la 
qualite de la bande passante de I'utilisateur. II s'avere alors judicieux 
d'informer celui-ci que son action est en cours de traitement. 



Faire patienter I'utilisateur avec un « loader » 

Lune des manieres les plus traditionnelles d'y parvenir est d'afficher une 
petite animation chargee par le navigateur au chargement de la page, a 
l'origine cachee grace a une propriete CSS adequate. 

Formulaire de recherche a remplacer dans le fichier apps/frontend/templates/layoutphp 

<div class="search"> 
<h2>Ask for a job</h2> 

<form action="<?php echo url for('@job search') ?>" 

method="get"> 

<input type="text" name="query" val ue="<?php echo 
$sfrequest->getParameter(' query') ?>" id="search keywords" /> 

<input type="submi t" val ue="search" /> 



ASTUCE Creer son propre loader 

Le loader par defaut est optimise pour le layout de 
Jobeet. Le site Internet suivant http:// 
www.ajaxload.info propose aux developpeurs 
un moyen simple de generer leurs propres images 
de chargement a partir d'une large banque de loa- 
ders predefinis. Un formulaire de generation invite 
I'utilisateur a determiner I'image de chargement a 
utiliser ainsi que la couleur des avant et arriere 
plans a partir de leur code hexadecimal respectif. 
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Remarque JavaScript comme une action 

Bien que le code JavaScript execute jusqu'a pre- 
sent pour le moteur de recherche soit statique, il 
arrive parfois d'avoir besoin d'appeler du code 
PHP (par exemple pour utiliser le helper 
url_for()). 

JavaScript n'est en fait qu'un format de plus 
comme le HTML, et comme on I'a vu dans les cha- 
pitres precedents, le framework Symfony permet la 
gestion des differents formats de sortie avec une 
grande simplicity. Dans la mesure ou le fichier 
JavaScript contiendra le comportement pour une 
page, il est possible d'obtenir la meme URL pour le 
fichier JavaScript a ceci pres qu'elle se terminera 
par I'extension .js. Par exemple, si Ton souhaite 
creer un fichier pour le moteur de recherche, il 
suffit d'editer la route job_search comme ci- 
dessous, puis de creer le template associe 
searchSuccess . js . php. 
job_search: 

url : /search. :sf_format 
param: { module: job, action: 
search, sf_format: html } 

requi rements : 
sf_format: (?:html | js) 



<img id="loader" src="/images/"loader .gif" style="vertical - 
align: middle; display: none" /> 

<div class="help"> 

Enter some keywords (city, country, position, ...) 

</di v> 
</form> 
</di v> 



Deplacer le code JavaScript dans un fichier externe 

Pour l'instant, le code JavaScript implemente pour faire fonctionner le 
formulaire de recherche ne dispose pas encore d'une place dediee dans le 
projet. L'ideal est done de deplacer ce code JavaScript autonome dans un 
fichier search, js, sauvegarde dans le repertoire web/js/. 

Contenu du fichier web/js/search.js 

: $(document) . ready (functi on () 
{ 

$(' .search input[type="submit"] ') .hide() ; 

$('#search_keywords ' ) . keyup (functi on (key) 
{ 

if (this. value. length >= 3 | | this. value == '') 
{ 

$('#loader').show(); 

$('#jobs').load( 

$(this) .parents('form') . attr(' action') , 
{ query: this. value + '*' }, 
functionO { $('#loader ') .hide() ; } 

); 

} 

}); 
}); 

La methode jQuery load() definit a present une nouvelle fonction ano- 
nyme de rappel (callback) en troisieme argument. Cette nouvelle fonc- 
tion est appelee automatiquement lorsque la requete Ajax est 
completement terminee. Elle a done en charge de masquer a nouveau 
l'image de chargement lorsque la page a bien ete mise a jour. 

Maintenant que le fichier search. js est cree, il ne reste plus qua 
l'appeler dans le layout afin qu'il soit charge par le navigateur pour 
chaque page du site. 

Appel du fichier search.js dans le fichier apps/frontend/templates/layoutphp 

<?php use_javascript(' search. js') ?> 
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Manipuler les requetes Ajax dans les actions 



Si JavaScript est active, jQuery interceptera les touches appuyees par 
l'utilisateur dans le formulaire de recherche, puis appellera ensuite 
Taction search du module job. Cette meme action sera aussi executee si 
JavaScript est desactive lorsque l'utilisateur soumettra le formulaire en 
pressant la touche Entree de son clavier, ou bien en cliquant le bouton 
search visible a l'ecran. 

Determiner que Taction provient d'un appel Ajax 

Quel que soit l'etat du support du JavaScript dans le navigateur, Faction 
search sera toujours executee pour le formulaire de recherche. II est alors 
naturel de se demander de quelle maniere il est possible de differencier une 
requete HTTP classique d'une requete en provenance d'un appel Ajax. 

La reponse se trouve en realite dans les en-tetes envoyes au serveur. En 
effet, un appel Ajax transmet sa requete au serveur avec l'en-tete X- 
Requested-With qui porte la valeur XMLHttpRequest. Cette information 
est en revanche absente des en-tetes pour une requete HTTP tradition- 
nelle. L'objet sfWebRequest du framework Symfony integre une methode 
i sXml HttpRequestO qui retourne la valeur true si la requete appelee pro- 
vient d'un appel Ajax. 

Implementation de la methode isXmlHttpRequestO dans Taction search du fichier 
apps/frontend/modules/job/actions/actions.class.php 

public function executeSearch(sfWebRequest Srequest) 
{ 

if (!$query = $request->getParameter('query')) 
{ 

return $thi s->forward( ' job ' , 'index'); 

} 

$this->jobs = Doctrine: :getTable('3obeetJob') 
->getForLuceneQuery($query) ; 

i f ($request->i sXnfl HttpRequest ()) 
{ 

return $this->renderPartial ( ' job/list' , arrayC jobs' => 
$this->jobs)) ; 
} 

} 

Dans la mesure ou jQuery ne rechargera pas la page entiere mais rem- 
placera uniquement le contenu de 1' element DOM #jobs par le contenu 
HTML de la reponse, la decoration de la page par le layout doit etre 
desactivee. Retirer le layout dans le cadre d'une requete Ajax est un 



Pratique isXmlHttpRequestO 
et les frameworks JavaScript 

La methodei sXml HttpRequestO de l'objet 
sfWebRequest de Symfony fonctionne avec la 
majorite des librairies JavaScript actuelles telles 
que Prototype, Mootools, Dojo et jQuery bien sur. 
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ASTUCE Retourner un composant 

De la meme maniere qu'avec la methode 
renderParti al (), il existe une methode 
renderComponentO qui permet de retourner 
le contenu genere a la suite de I'execution d'un 
composant. Cette methode accepte trois arguments 
dont les deux premiers sont obligatoires. Le premier 
parametre correspond au nom du module dans 
lequel se situe le composant alors que le second est 
le nom du composant a executer. Enfin, le troisieme 
argument facultatif est un tableau associatif de 
variables a transmettre au composant. 



besoin frequent, c'est pour cette raison que c'est le comportement adopte 
par defaut dans Symfony. 

De plus, au lieu de retourner l'integralite du template, on se contente uni- 
quement de renvoyer le contenu du template partiel job/1 i st. La methode 
renderParti al () employee dans Taction retourne le partiel evalue en guise 
de reponse au lieu du template searchSuccess . php complet. 

Message specifique pour une recherche sans resultat 

Pour l'instant, la requete Ajax retourne toujours le meme template, qu'il 
y ait des resultats ou non. Le scenario ideal consiste done a informer 
l'utilisateur si aucun resultat ne correspond a sa recherche en lui affi- 
chant un court message a la place d'une page blanche. La methode 
renderTextO permet de realiser ce type d'operation sans effort comme 
l'explique le code ci-dessous. 

Implementation de la methode renderTextO dans Taction search du fichier apps/ 
frontend/modules/job/actions/actions.class.php 

public function executeSearch(sfWebRequest Srequest) 
{ 

if (!$query = $request->getParameter('query')) 
{ 

return $this->forward(' job' , 'index'); 

} 

$this->jobs = Doctrine: :getTable(' JobeetJob') 

->getForl_uceneQuery($query) ; 

if ($request->i sXml HttpRequestO) 
{ 

if ('*' == $query || ! $this->jobs) 
{ 

return $this->renderText( ' No results.'); 

} 

else 
{ 

return $thi s->renderPartial ('job/list' , 

arrayC jobs' => $thi s->jobs)) ; 

} 

} 

} 
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Simuler une requete Ajax avec les tests j 
fonctionnels t 

Comme le navigateur interne de Symfony est incapable d'executer ou de -S 
simuler du code JavaScript, les tests fonctionnels de la recherche en temps t 
reel sont alors impossibles. Neanmoins, il reste toujours la possibilite de '1 
tester les appels Ajax en fournissant manuellement FURL a atteindre avec J. 
ses parametres ainsi que l'en-tete X_REQUESTED_WITH qu'envoient tous les ^ 
frameworks JavaScript comme jQuery avec sa requete Ajax. Le template " 
partiel des offres d'emploi rendu en guise de reponse a une requete Ajax 
peut ainsi etre teste a l'aide du testeur response. 

Scenario de tests fonctionnels a ajouter au bas du fichier test/functional/frontend/ 
jobActionsTest.php 

$browser->setHttpHeader('X REQUESTED WITH' , 'XMLHttpRequest') ; 

$browser-> 

infoC'5 - Live search ')-> 

get( '/search?query=sens* ' )-> 
with(' response ')->begin()-> 

checkElement(' table tr', 3)-> 
end() 

La methode setHttpHeader() fixe un en-tete HTTP pour la toute pro- 
chaine requete appelee avec le navigateur interne de Symfony. 



En resume... 

Le chapitre precedent a montre pas a pas comment implementer un 
moteur de recherche entierement fonctionnel grace a la technologie 
Zend Lucene. Ce chapitre a de son cote permis d'ameliorer 1' experience 
utilisateur en rendant le moteur plus reactif grace a l'implementation 
d'une recherche en temps reel mise en place grace a jQuery. 

Le framework Symfony fournit non seulement tous les outils essentiels 
pour construire des applications MVC en toute simplicite, mais 
s'accorde en plus tres bien avec de nombreux autres composants. 
Comme toujours, il convient d'avoir recours aux meilleurs outils pour 
chaque tache dediee, et c'est exactement comme 9a que se comportent 
Zend Lucene pour la recherche et jQuery pour le JavaScript. 

Le chapitre suivant aborde un nouveau point essentiel des applications 
web professionnelles : l'internationalisation et la regionalisation. II sera 
question du support de differentes cultures de l'utilisateur, de traduction 
de contenus, de traduction d'offres d'emploi en base de donnees ou bien 
encore des formatages de dates ou de monnaies par exemple. 
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Nombreux sont les sites Internet qui disposent d'une interface 

multilingue pour leurs utilisateurs. La traduction 

d'une application web en differentes langues n'est pas une 

tache aisee pour les developpeurs car elle implique de faire 

face a de nombreuses contraintes. Parmi elles figurent bien 

evidemment les traductions des contenus statiques 

et dynamiques (base de donnees, pluriels), le sens de lecture 

de la langue ou bien encore le formatage des dates, heures, 

nombres et autres devises monetaires. 

Le framework Symfony integre de nombreux outils pour 
repondre a tous ces besoins, explicites dans ce dix-huitieme 
chapitre. 



► Interface multilingue 

► Traduction de contenus 

► Formatage des dates 
et monnaies 



Le developpement de l'application Jobeet est sur le point de toucher a sa 
fin. De nombreuses fonctionnalites ont ete implementees tout au long 
de cet ouvrage pour rendre l'application a la fois dynamique, fonction- 
nelle, confortable a prendre en main de part l'ecriture de code JavaScript 
non-intrusif, et enfin, dans l'air du temps grace a ses flux de syndication 
de contenu et ses autres services web. 



Culture Informative 
Origine des abreviations I18N et L10N 

Les termes internationalisation et localisation, par- 
ticulierement contraignants a ecrire, ont ete res- 
pectivement abreges en 11 8N et L10N. Ces 
abreviations n'ont pas ete tres difficiles a trouver, 
puisque 11 8N vient tout simplement du fait qu'il y 
a 18 lettres entre le / et le n du terme anglais 
internationalization. Sur le meme principe, 
I'abreviation du terme anglais localization a con- 
duit a L1 ON. 



Que sont I'internationalisation et la 
localisation ? 

C'est done le moment de s'interesser a la mise en place d'une interface 
multilingue pour Jobeet afin de permettre aux utilisateurs francophones 
et anglophones de naviguer a travers les offres d'emploi dans la langue 
qui leur convient le mieux. De nombreux ajustements a travers toute 
l'application devront etre operes pour repondre a ce besoin, mais heureu- 
sement le framework Symfony dispose de tous les outils necessaires pour 
simplifier l'integration de I'internationalisation (I18N) et de la localisa- 
tion (LION) d'un projet. A quoi correspondent exactement ces deux 
concepts ? Qu'est-ce qui les differencie ? 

L'internationalisation, traditionnellement abregee I18N, concerne tout 
le processus de conception d'une application logicielle ayant vocation a 
etre adaptee pour de multiples langues et regions sans qu'il y ait besoin 
de changements techniques. 

La localisation, egalement nommee regionalisation et abregee LION, 
correspond au processus d'adaptation d'une application logicielle pour 
une region ou une langue specifique, en integrant des composants pro- 
pres a cet element local (par exemple : formatage des dates, heures, 
nombres, monnaies...) ainsi que la traduction des textes. 

Comme toujours, le framework Symfony ha pas reinvente la roue et doit son 
support natif de iinternationalisation et de la localisation au standard ICU. 

Technology Le standard ICU 

ICU est I'acronyme pour International Components for Unicode. Initialement deve- 
loppee et supportee par les plateformes C, C++ et Java, la bibliotheque Open Source ICU est 
devenue une solution portable reconnue pour le traitement de textes internationaux. Avec le 
temps, de nombreux portages ont ainsi pu etre realises sur differents langages de programma- 
tion, d'apres la librairie C originale. ICU fournit un certain nombre de fonctionnalites telles que 
la conversion des contenus en (et depuis) Unicode, la comparaison de chatnes de caracteres, le 
formatage des dates, nombres, heures et devises ou bien encore les calculs temporels en fonc- 
tion du calendrier local. Pour en savoir plus au sujet du standard ICU, nous vous invitons a 
consulter le site officiel a I'adresse http://site.icu-project.org/ 



352 



L'utilisateur au cceur de 
rinternationalisation 

L'utilisateur est au coeur du processus d'internationalisation de Implica- 
tion, car sans lui ce concept n'a aucune raison d'etre. En effet, lorsqu'un 
site Internet est disponible en plusieurs langues ou pour differentes 
regions du monde, l'utilisateur est responsable du choix de celle qui lui 
convient le mieux. C'est pour cette raison que dans Symfony, la notion 
de « culture » est propre a l'utilisateur courant pour englober tout ce qui 
concerne les problematiques d'internationalisation et de localisation. 



Reference L'objet sfUser 



L'ensemble des concepts et fonctionnalites propres 
a l'utilisateur comme la culture ou bien les droits 
d'acces ont ete presented au chapitre 1 3 de cet 
ouvrage. 



Parametrer la culture de l'utilisateur 

Les fonctionnalites d'internationalisation et de localisation de Symfony 
reposent toutes sur la culture de l'utilisateur qui reside dans sa session 
persistante. La culture est en fait la combinaison de deux elements pro- 
pres a l'utilisateur : sa langue et son pays. Par exemple, la culture d'une 
personne qui park le francais est f r tandis que la culture pour une per- 
sonne francaise qui habite en France est f r_FR. Les sections qui suivent 
presentent les differentes manieres de fixer la valeur de la culture de l'uti- 
lisateur et comment agir avec elle. 

Definir et recuperer la culture de l'utilisateur 

L'objet sfUser dispose de deux methodes tres pratiques pour gerer la 
valeur de la culture qui lui est associee. II s'agit des methodes 
setCultureO et getCulture() qui permettent respectivement de fixer la 
valeur de la culture et de l'obtenir. 

// Depuis les actions 
$this->getUser()->setCulture('fr_BE') ; 
echo $this->getUser()->getCulture() ; 

// Depuis les templates 
$sf_user-> setCulture('fr_BE') ; 
echo $sf_user->getCulture() ; 



Modifier la culture par defaut de Symfony 

Par defaut, la culture de l'utilisateur est automatiquement initialisee avec 
la valeur de la culture inscrite initialement dans le fichier de configura- 
tion settings. yml de l'application, a la section default_culture. Cette 
directive de configuration peut alors etre redefinie pour attribuer une 
nouvelle culture par defaut a tous les nouveaux utilisateurs arrivant sur 
l'application. 



Convention Formatage de la culture 

La valeur de la culture est un format normalise. En 
effet, la langue est codee sur deux caracteres 
minuscules comme le specifie le standard ISO 639- 
1 alors que le pays est code avec deux caracteres 
en majuscules, d'apres les specifications du stan- 
dard ISO 3166-1. 



ASTUCE Changer de culture 

Dans Symfony, la culture est geree par l'objet User, 
et est notamment sauvegardee dans la session 
persistante de ce dernier. Au cours du developpe- 
ment, si la culture par defaut est amenee a etre 
modifiee, alors il sera necessaire de vider les coo- 
kies de session du navigateur afin que la nouvelle 
configuration soit prise en compte par le naviga- 
teur, et que les changements sur I'interface pren- 
nent effet immediatement. 



353 



Modification de la valeur par defaut de la culture dans le fichier de configuration 
apps/frontend/config/settings.yml 

all : 

. setti ngs : 
default culture: it IT 

Determiner les langues favorites de I'utilisateur 

Pour un site international, il n'est pas toujours judicieux de forcer la 
valeur de la langue par defaut pour I'utilisateur. En effet, si un utilisateur 
anglophone arrive sur le site et que la langue par defaut pour ce dernier 
est le francais, il se sentira contraint de changer lui-meme la langue du 
site. Cela a pour effet immediat dans le meilleur des cas de lui faire 
recharger la page sur laquelle il se trouve, ou dans le pire de lui faire 
quitter definitivement le site. . . 

Lideal est done de fixer la valeur de la culture par defaut d'apres les informa- 
tions transmises par le navigateur dans l'en-tete HTTP Accept-Language. 
En effet, cet en-tete envoie au serveur une liste predefinie des langues du 
navigateur, d'apres sa configuration. Les langues par defaut du navigateur 
presentes dans cette liste sont triees les unes par rapport aux autres par ordre 
de preference. Ainsi, si le navigateur indique au serveur qu'il est parametre a 
cet instant en langue anglaise, e'est qu'il y a fort a parier que I'utilisateur qui 
se trouve face a l'ecran parle, lit et comprend l'anglais. 

Sachant cela, il parait pertinent de s'appuyer sur cette information pour 
fixer automatiquement la langue par defaut de I'utilisateur. Dans Sym- 
fony, e'est l'appel aux methodes getl_anguages() et 
getPreferredCultureO de l'objet sfWebRequest qui permet de deter- 
miner la configuration du navigateur. La methode getLanguagesO de 
l'objet de requete a pour role de renvoyer un tableau des langues suppor- 
tees par le navigateur du client. 

// Depuis une action 

Slanguages = $request->getl_anguages() ; 

Neanmoins, la plupart du temps, 1' application web ne sera pas dispo- 
nible pour les 136 langues majeures de la planete ; e'est pourquoi il est 
preferable d'avoir recours a la methode getPreferredCultureO qui se 
charge de deviner et de retourner la meilleure langue en comparant les 
langues predefinies du navigateur du client avec celles qui sont suppor- 
tees par le site web. 

// Depuis une action 

Slanguage = Srequest->getPreferredCulture(array('en' , 'fr')); 



Lors de 1' execution de cet appel a getPreferredCultureO, la langue ren- 
voyee par la methode sera l'anglais ou le francais d'apres la liste des langues 
par defaut du navigateur de l'utilisateur. Si aucune des deux ne correspond, 
alors c'est la premiere du tableau passe en parametre qui est choisie. 

Utiliser la culture dans les URLs 

Le site Internet de Jobeet sera disponible en deux langues : anglais et 
francais. II est important de rappeler qu'une URL represente unique- 
ment une seule ressource, et pour l'instant toutes les URLs de Jobeet ne 
sont pas adaptees pour acceder a une meme ressource disponible dans 
deux langues differentes. Les prochaines sections expliquent comment 
prendre en compte la notion de culture dans les URLs et comment redi- 
riger automatiquement l'utilisateur sur la page qui lui correspond le 
mieux des son arrivee sur le site, d'apres la configuration de son naviga- 
teur envoyee au serveur. 

Transformer le format des URLs de Jobeet 

Lensemble des pages du site Internet de Jobeet sera accessible dans les 
deux langues, ce qui implique qu'il faille obligatoirement remanier le 
format des URLs, afin que l'utilisateur puisse distinguer clairement sur 
quelle version du site il se trouve. Pour resoudre cette problematique, il 
est necessaire de rouvrir le fichier de configuration routing. yml et 
d'editer toutes les routes, a l'exception des routes api_jobs et homepage, 
pour qu'elles embarquent la variable speciale sf_culture. Les routes 
simples se dotent a present du motif /: sf_cu"lture au debut de FURL 
tandis que les collections de routes surchargent leur option de configura- 
tion respective prefix_path avec /:sf_culture en tete. 

Integration de la variable speciale sf_culture dans les URLs du fichier apps/frontend/ 
config/routing.yml 

af f i 1 i ate : 

class : sfDoctri neRouteCollection 
options : 

model : JobeetAf f i 1 i ate 

actions: [new, create] 

object_actions : { wait: get } 

prefix path: /:sf culture/affil iate 

category: 

url : /:sf culture/category/: slug. :sf format 

class: sfDoctri neRoute 

param: { module: category, action: show, sf_format: html } 
options: { model: JobeetCategory , type: object } 
requi rements : 

sf_format: (?: html | atom) 



Choix de conception Definir la langue d'apres 
la configuration du navigateur 

II faut garder a I'esprit que cette technique n'est 
pas fiable a 100% dans la mesure ou elle 
n'exclut pas par exemple qu'un utilisateur 
etranger se trouve devant un poste qui ne lui 
appartient pas. Le cas le plus typique est lorsque 
l'utilisateur se connecte depuis I'ordinateur d'un 
cybercafe d'un pays etranger ou il sejourne pour 
ses vacances. 
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job_search : 

url : /: sf_cul ture/search 

param: { module: job, action: search } 

job: 

cl ass : sfDoctri neRouteCol 1 ecti on 
options : 

model : JobeetJob 

column: token 

object_actions : { publish: put, extend: put } 
prefix path: /:sf culture/job 

requi rements : 
token: \w+ 

job_show_user: 

url : /:sf culture/job/: company slug/ location slug/:id/ 
:position_slug 

class: sfDoctri neRoute 
options : 

model : Jobeetlob 

type: object 

method_for_query : retrieveActi veJob 
param: { module: job, action: show } 
requi rements : 

id: \d+ 

sf_method: get 

Lorsque la variable sf_culture est presente dans une route, Symfony 
utilise automatiquement sa valeur pour changer la culture de l'utilisateur. 
Neanmoins, l'objectif est de rediriger ce dernier directement sur la ver- 
sion traduite du site qui lui correspond au mieux d'apres la configuration 
de son navigateur. 

Attribuer dynamiquement la culture de l'utilisateur d'apres la 
configuration de son navigateur 

L'application Jobeet a besoin d'autant de pages d'accueil que de langues 
supportees (/en/, /f r/, etc.), c'est pourquoi la page d'accueil par defaut 
doit rediriger l'utilisateur vers celle qui correspond a la culture qu'il a 
selectionnee. Or, a son premier passage sur le site, cette derniere nest pas 
encore definie et l'utilisateur se voit automatiquement attribue la culture 
par defaut du fichier de configuration settings. yml. Dans l'ideal, il 
serait plus judicieux de definir sa culture dynamiquement en se basant 
sur la liste des langues configurees dans son navigateur et transmises 
dans les en-tetes de la requete HTTP. 

Declarer une route pour la page d'accueil regionalisee 

Comme toujours, une ressource est rendue accessible a condition qu'une 
nouvelle route dediee lui soit consacree dans le fichier de configuration 



routing. yml. Le code ci-dessous est a ajouter au fichier routing. yml. II 
declare une route local ized_homepage qui fait usage de la variable spe- 
ciale sf_culture de Symfony pour determiner dans quelle langue sera 
rendue la page d'accueil de Jobeet. La section requi rements etablit une 
regie pour forcer la valeur de la variable sf_culture a f r ou en. 

Declaration de la route localized_homepage dans le fichier apps/frontend/config/ 
routing.yml 

1 ocal i zed_homepage : 
url : /:sf culture/ 
param: { module: job, action: index } 
requi rements : 

sf culture: (?:fr|en) 

L'etape suivante consiste a implementer la methode isFi rstRequestO 
suivante dans la classe myUser de l'application f rontend. Cette methode 
retourne une valeur booleenne indiquant si oui ou non l'utilisateur arrive 
pour la premiere fois sur le site Internet, en stockant cette derniere dans 
une variable de session. 

Implementation de la methode isFirstRequestO dans la classe myUser du fichier 
apps/frontend/lib/myUser.class.php 

public function i sFi rstRequest($bool ean = null) 
{ 

if (is_null (Sboolean)) 
{ 

return $thi s->getAttri bute( ' f i rst_request ' , true); 

} 

el se 
{ 

$this->setAttribute('fi rst_request' , Sboolean) ; 

} 

} 

Ceci etant fait, il ne reste plus qua implementer cette methode dans 
Taction i ndex du module job pour determiner automatiquement la culture 
qui correspond au mieux a l'utilisateur d'apres la configuration du naviga- 
teur que ce dernier envoie au serveur par le biais des en-tetes HTTP. 

Determiner la meilleure culture pour l'utilisateur 

Pour finaliser la detection automatique de la meilleure culture a attribuer 
a l'utilisateur a sa premiere arrivee sur l'application Jobeet, il est neces- 
saire d'implementer la logique metier relative a ce besoin dans la 
methode executelndex() du module job. Cette derniere fait appel a la 
methode i sFi rstRequestO definie juste avant pour determiner s'il s'agit 
ou non du premier passage de l'utilisateur sur la page d'accueil de Jobeet. 



Implementation de la logique metier de determination de la meilleure culture de 
I'utilisateur dans le fichier apps/frontend/modules/job/actions/actions.class.php 

public function executeIndex(sfWebRequest Srequest) 
{ 

if ( ! $request->getParameter ( ' sf cul ture' )) 
{ 

i f ($thi s->getUser () ->i sFi rstRequest ()) 
{ 

$cu"lture = $request->getPreferredCu"lture(array('en' , 'fr')); 
$this->getl)ser () ->setCul ture($cul ture) ; 
$this->getl)ser()->isFi rstRequest (fal se) ; 

} 

el se 
{ 

$culture = $this->getUser()->getCulture() ; 

} 

$thi s->redi rect ( ' @1 ocal i zed homepage ' ) ; 

} 

$this->categories = Doctri ne : : getTabl e( ' JobeetCategory ' )- 
>getWith]obs() ; 
} 

Limplementation de ces quelques nouvelles lignes de PHP merite quel- 
ques explications. La premiere condition verifie que la variable 
sf_culture n'est pas presente dans la requete, ce qui signifie aussi que 
I'utilisateur est entre sur le site depuis FURL racine / definie par la route 
homepage. Si c'est effectivement le cas et que I'utilisateur arrive pour la 
premiere fois de sa session sur le site, alors on lui affecte la culture qui 
correspond au mieux a la configuration de son navigateur. Dans le cas 
contraire, c'est sa culture courante qui est utilisee. 

Enfin, I'utilisateur est redirige automatiquement vers la page d'accueil 
(route local ized_homepage) traduite dans sa langue. II est bon de noter 
que la variable sf^culture n'est pas passee explicitement dans l'appel de 
la redirection puisque Symfony se charge de l'ajouter lui-meme d'apres 
la valeur de la culture fixee dans l'objet sf User. 

Restreindre les langues disponibles a toutes les routes 

La route local ized_homepage etablit une contrainte forte dans sa section 
requi rements afin de forcer la variable sf_culture aux deux seules valeurs 
f r et en. De ce fait, si un utilisateur tente d'acceder a la page d'accueil de 
Jobeet via l'URL /i t/, Symfony retournera automatiquement une page 
d'erreur 404. II est done important de securiser l'ensemble des routes de 
Jobeet qui embarquent la variable sf_culture en leur ajoutant a chacune 
cette restriction dans le fichier de configuration routi ng . yml . 

requi rements : 

sf_culture: (?:fr|en) 



Tester la culture avec des tests fonctionnels 



Mettre a jour les tests fonctionnels qui echouent 

Le moment est venu de s'interesser de nouveau aux tests fonctionnels dans 
la mesure ou une nouvelle fonctionnalite a ete implemented et que toutes 
les URLs ont ete modifiees. La modification des URLs entraine naturelle- 
ment l'echec des tests fonctionnels, c'est pourquoi il faut d'abord les cor- 
riger avant d'en ajouter de nouveaux. La resolution des tests fonctionnels 
errones necessite seulement d'ajouter la chaine /en au debut de toutes les 
URLs des fichiers de tests du repertoire test/functional /frontend, y 
compris dans le fichier lib/test/JobeetTestFunctional .class. php. 
Lexecution de toute la suite de tests fonctionnels permet de s' assurer que 
tous les tests ont ete correctement fixes. 

J $ php symfony test: functional frontend 

Tester les nouvelles implementations liees a la culture 

La prise en compte de la culture dans les URLs ainsi que l'implementa- 
tion de la selection automatique de la culture de l'utilisateur a son arrivee 
sur le site conduisent a ecrire trois nouveaux scenarios de test, dont voici 
le descriptif : 

• la culture de l'utilisateur est devinee automatiquement par Symfony a 
sa premiere requete ; 

• les seules cultures disponibles sont f r et en, les autres provoquent des 
pages d'erreur 404 ; 

• la culture de l'utilisateur est devinee uniquement a sa premiere 
requete. 

Le testeur user inclut une methode isCultureO qui teste la valeur de la 
culture courante de l'utilisateur. C'est cette methode qui est majoritaire- 
ment employee dans ces trois scenarios de tests. Le code ci-dessous 
definit la suite de tests de ces trois scenarios dans le fichier 
JobActionsTest. 

Tests fonctionnels de la culture dans le fichier test/functional/frontend/ 
jobActionsTest.php 

$browser->setHttpHeader(' ACCEPT LANGUAGE' , 

'fr FR,fr,en;q=0.7'); 

$browser-> 

info('6 - User culture')-> 



restart ()-> 



info(' 6.1 - For the first request, symfony guesses the best 
culture')-> 
get(7')-> 

isRedi rected()->followRedi rect()-> 
wi th ( ' user ' ) ->i sCul ture( ' f r ' ) -> 

info(' 6.2 - Available cultures are en and fr')-> 
get('/it/')-> 

with( ' response ' )->i sStatusCode(404) 

$browser->setHttpHeader('ACCEPTJJVNGUAGE' , ' en.fr ;q=0. 7') ; 

$browser-> 

info(' 6.3 - The culture guessing is only for the first 
; request')-> 

get('/')-> 

isRedi rected()->followRedi rect()-> 
wi th ( ' user ' ) ->i sCul ture( ' f r ' ) 

Ici, la presence de la methode restart () permet de reinitialiser le naviga- 
teur de tests, et plus particulierement les cookies et la session de l'utilisateur 
qui contient la valeur de la culture. Pour s'assurer que la langue favorite de 
l'utilisateur est bien definie automatiquement par Symfony, l'en-tete 
ACCEPT_LANGUAGE adequat doit etre envoye au serveur a l'aide de la methode 
setHttpHeader() du navigateur de tests. Enfin, la methode isCultureO 
du testeur user permet de controler la valeur de la culture attribuee a l'utili- 
sateur par le framework lors de ses differentes requetes au serveur. 

Changer de langue manuellement 

Pour l'instant la culture de l'utilisateur est definie automatiquement a son 
arrivee sur le site de Jobeet. Neanmoins, cette methode d' attribution de la 
culture n'est pas fiable a cent pour cent dans la mesure ou elle n'exclut pas 
qu'un utilisateur se connecte depuis un ordinateur qui n'est pas le sien, et 
qui par consequent est potentiellement configure differemment. 

C'est par exemple le cas pour un utilisateur qui se connecte au site depuis 
un cybercafe d'un pays etranger dans lequel il sejourne temporairement. 
Pour cette raison, il convient de mettre en place un moyen lui permet- 
tant de changer manuellement la langue dans laquelle il souhaite con- 
suiter le site. Avec Symfony, ceci peut etre realise tout simplement a 
l'aide d'un composant entierement fonctionnel figurant dans le plug-in 
officiel sfFormExtraPlugin. 



Installer le plug-in sfFormExtraPlugin 

Afin que l'utilisateur puisse changer de langue manuellement, un formu- 
laire de selection de langue doit etre ajoute dans le layout de l'application. 
Le framework de formulaire de Symfony ne fournit pas ce type de fonc- 
tionnalite nativement mais comme il s'agit d'un besoin particulierement 
recurrent dans les sites a vocation internationale, l'equipe de developpe- 
ment de Symfony a developpe et maintient le plug-in sf FormExtraPl ugi n. 

Ce plug-in contient un certain nombre de validateurs, de widgets et 
d'autres formulaires qui ne peuvent etre inclus par defaut dans le fra- 
mework dans la mesure oil ils sont trop specifiques, ou parce qu'ils pos- 
sedent des dependances externes avec d'autres composants tels que le 
framework JavaScript jQuery par exemple. 

Comme toujours, l'installation d'un plug-in est automatisee avec l'aide 
de la commande pi ugi n : i nstal 1 de Symfony 

| $ php symfony pi ugi n : i nstall sfFormExtraPlugin 

Comme de nouvelles classes sont livrees par le plug-in, le cache de Sym- 
fony doit etre vide afin de les prendre en compte dans le fichier d'auto- 
chargement de classes. 

j $ php symfony cc 

Integration non conforme du formulaire de changement de langue 

Le plug-in sfFormExtraPlugin fournit la classe de formulaire 
sf FormLanguage pour gerer la selection d'une langue parmi une liste pre- 
definie d'autres langues. L'ajout de ce formulaire peut etre realise direc- 
tement dans le layout, bien que ce ne soit pas du tout la meilleure 
maniere de proceder... 

<div i d="footer"> 

<div class="content"> 
<!-- footer content --> 

<?php $form = new sf FormLanguage ( 
$sf user , 

arrayC languages' => arrayC'en', 'fr')) 
) 

?> 

<form action="<?php echo url for('@change language') ?>"> 

<?php echo $form ?><input type="submi t" value="ok" /> 
</form> 
</di v> 
</di v> 



ASTUCE Utiliser des widgets « riches » 

Le plug-in sfFormExtraPlugin contient de 
nombreux widgets qui necessitent l'installation de 
dependances externes comme des librairies Java- 
Script telles que jQuery ou TinyMCE. Parmi les 
composants livres par ce plug-in figurent un 
widget de selection de dates en JavaScript {date 
picker), un editeur WYSIWYG base sur le celebre 
TinyMCE, un systeme antispam (« captcha ») repo- 
sant sur le service ReCaptcha, une boite de saisie 
d'autocompletion a la maniere de celle de Google, 
etc. II suffit de lire la documentation de ces outils 
supplementaires sur le site officiel de Symfony afin 
de decouvrir bien d'autres surprises utiles. 



AVERTISSEMENT Contre-exemple 
d'installation du formulaire 
a ne pas reproduire ! 

Le code presente ici n'a aucune vocation a etre 
implements de cette maniere car il ne se con- 
forme pas a la logique du modele de conception 
MVC ! II sert uniquement en guise d'exemple 
pour montrer ce qu'il ne faut pas faire ni etre 
tente de faire par la suite. II s'agit en effet d'une 
mauvaise pratique a ne pas reproduire dans de 
futurs developpements. La suite de cette section 
explique comment I'implementer proprement 
dans Symfony. 
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Integration du formulaire de changement de langue avec un 
composant Symfony 



Les composants Symfony a la rescousse 

Le code precedent revele un gros defaut de conception. II s'agit de la crea- 
tion du formulaire qui ne se trouve pas du tout a sa place selon les prin- 
cipes etablis par le modele MVC. En effet, la creation du formulaire 
n'appartient aucunement a la couche de la Vue mais a celle du Controleur, 
c'est pourquoi ce bout de code doit etre deplace dans une action dediee. 

Le probleme qui se pose ici est que le formulaire de changement de langue 
appartient au layout car il doit etre present sur chaque page du site. La 
solution qui en decoule est alors d'instancier la classe sf FormLanguage dans 
chacune des actions du site, ce qui est loin d'etre tres pratique et DRY. . . 
Heureusement avec Symfony, chaque probleme a sa solution propre, et 
dans le cas present il s'agit de faire appel aux composants. 

Que sont les composants dans Symfony ? 

Dans Symfony, un composant est en realite un template partiel auquel 
est attache du code metier, ce qui est finalement comparable a une action 
allegee. Comme les actions, les composants dependent tous d'un 
module, ce qui implique qu'il faille creer un fichier 
components. cl ass. php dans le repertoire actions/ d'un module. 

Ce fichier contiendra la classe nomDuModuleComponents des differents 
composants rattaches a ce module. Enfin, chaque composant developpe 
dans cette classe est en realite une methode avec du code metier a 
laquelle est associe un template partiel du meme nom que le composant. 

Letape finale de mise en place d'un composant est bien evidemment son 
appel depuis un template qui se realise a l'aide du helper 
-inc"lude_component() comme le montre l'exemple de code ci-dessous. 

Integration du composant language dans le fichier apps/frontend/templates/ 
layout.php 

<div id="footer"> 

<div class="content"> 
<!-- footer content --> 

<?php include component (' language ' , 'language') ?> 

</di v> 
</di v> 

Le helper inc"lude_component() accepte deux arguments obligatoires qui 
correspondent respectivement au nom du module dans lequel se situe le 
composant et enfin Taction a appeler dans la classe de composants. Dans le 



cas present, le composant ira chercher Taction 1 anguage des composants du 
module language qui n'existe pas encore. Ce helper est capable d'accueillir 
un troisieme parametre facultatif qui doit etre un tableau associatif de cou- 
ples variable/valeur necessaires au bon fonctionnement du composant. 

Implementer le composant de changement de langue 

La section suivante est relativement theorique, c'est pour cette raison 
qu'il convient de la mettre en pratique en developpant pas a pas le com- 
posant du formulaire de changement de langue. Pour y parvenir, cinq 
etapes successives sont a franchir : 

1 generer le module 1 anguage et creer le fichier components . cl ass . php ; 

2 developper la classe languageComponent et sa methode 
executeLanguageO ; 

3 creer le template du composant ; 

4 declarer une nouvelle route dediee pour Taction du formulaire ; 

5 developper la logique metier du changement de la culture de Tutilisa- 
teur. 

La premiere etape consiste done a generer le squelette du module 
language a Taide de la tache Symfony generate: module. 

| $ php symfony gene rate: module frontend language 

Une fois le module completement genere, le fichier des composants 
components. class. php doit etre cree manuellement dans le repertoire 
actions/ du module language, dans la mesure oil la tache 
gene rate: module ne le cree pas. Ce fichier contient la classe 
languageComponents dont le code figure ci-dessous. 

Contenu du fichier apps/frontend/modules/language/actions/components.class.php 

class languageComponents extends sfComponents 
{ 

public function executeLanguage(sfWebRequest $request) 
{ 

$this->form = new sf FormLanguage( 
$this->getUser() , 

arrayC languages' => arrayC'en', 'fr')) 

); 

} 

} 

Comme on peut le constater ici, une classe de composants se declare 
globalement de la meme facon qu'une classe d'actions. Le nom de la 
classe est compose du nom du module suffixe par Components et la classe 
derivee est cette fois-ci sfComponents. Les actions, quant a elles, s'ecri- 



vent toujours de la meme maniere. Ici, le composant language ne fait ni 
plus ni moins qu'instancier la classe sf FormLanguage avec ces parametres, 
puis transmet l'objet Sform a son template associe. 

La realisation du template du composant constitue la troisieme etape du 
processus de creation d'un composant. Comme pour les templates des 
actions, les templates des composants sont soumis a une convention de 
nommage particuliere. Le template d'un composant est en fait un tem- 
plate partiel portant le nom de Faction appelee. Le code ci-dessous est le 
contenu du fichier _language.php a creer dans le dossier templates/ du 
module language. 

Contenu du template partiel du composant language dans le fichier apps/frontend/ 
modules/language/templates/Janguage.php 

<form action="<?php echo url for ('©change language') ?>"> 

<?php echo $form ?><input type="submi t" value="ok" /> 
</form> 

Le composant est maintenant entierement pret. Letape suivante con- 
siste a le rendre fonctionnel a l'aide de Taction executee a l'appel de la 
route change_language. Dans un premier temps, celle-ci doit etre 
declaree dans le fichier routing. yml de l'application frontend. 

Route changejanguage a ajouter au fichier apps/frontend/config/routing.yml 

change_l anguage : 

url: /change_language 

param: { module: language, action: changeLanguage } 

La methode changeLanguage du module language a pour role de traiter 
la valeur transmise par le formulaire de changement de langue et de fixer 
la valeur de la culture de l'utilisateur, avant de rediriger ce dernier vers la 
page d'accueil traduite dans la langue qu'il a choisie. 

Implementation de Taction changeLanguage dans le fichier apps/frontend/modules/ 
language/actions/actions.class.php 

, class languageActions extends sf Actions 
{ 

public function executeChangeLanguage(sfWebRequest $request) 
{ 

$form = new sf FormLanguage( 
$this->getl)ser() , 

arrayC languages' => array('en', 'fr')) 

); 



$form->process($request) ; 



return $this->redirect('@1oca1ized homepage') ; 

} 

} 

Ici, c'est en realite la methode processO de l'objet sfFormLanguage qui 
se charge de controler la valeur soumise par l'utilisateur dans la requete, 
et d'affecter la nouvelle culture a l'objet myUser qui lui est passe en guise 
de premier parametre du constructeur. La capture d'ecran ci-dessous 
donne le resultat final de Integration du composant language dans le 
pied de page de Jobeet. 
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Figure 18-1 Rendu final du formulaire de changement de langue dans le pied de page de Jobeet 



Decouvrir les outils d'internationalisation 
de Symfony 

Le framework Symfony recele d'outils divers et varies pour simplifier la 
creation d'applications web internationalisees et regionalisees. Ce lot 
d'outils presentes dans les sections qui suivent comprend notamment le 
support des encodages, la traduction des contenus dans les templates, 
l'extraction de contenus internationalises des templates, des helpers de for- 
matage de dates, heures, nombres et monnaies, ou encore le support inte- 
gral des tables de traduction pour les objets Doctrine en base de donnees. 

Parametrer le support des langues, jeux de caracteres 
et encodages 

La monde comprend plus d'une centaine de langues officielles toutes 
autant variees les unes que les autres etant donne leurs specificites typo- 
graphiques (sens de lecture, lettres, symboles, ponctuation...). Cette 
large variete de langues explique pourquoi, dans le monde informatique, 
il existe autant de jeux de caracteres differents entre les langues. 



La langue anglaise est sans aucun doute la plus simple de toutes 
puisqu'elle fait appel uniquement a des caracteres de la table ASCII (se 
prononce « ASKI ») tandis que le francais est, quant a lui, un peu plus 
complexe en raison de ses caracteres accentues tels que e, ii, i. . . D'autres 
langues comme le russe, le chinois, ou l'arabe sont encore plus complexes 
dans la mesure ou leurs caracteres et/ou symboles typographiques sor- 
tent litteralement du cadre de la table ASCII, ce qui implique que ces 
langues sont definies avec des jeux de caracteres differents. 

Lorsqu'il s'agit de manipuler des donnees internationalisees, il est une 
bonne pratique d'utiliser la norme Unicode. Le concept sous-jacent 
d'Unicode est d'etablir un jeu de caracteres universel capable de contenir 
tous les caracteres de toutes les langues. Cependant, cela a un inconve- 
nient notable car un seul caractere code avec Unicode peut etre repre- 
sente avec plus de 21 bits. Par consequent, pour le web, c'est l'UTF-8 
qui est retenu car il fait correspondre les numeros de chaque caractere 
Unicode avec des sequences d'octets de longueur variable (de 1 a 
4 octets). En UTF-8, la plupart des langues ont leurs caracteres codes 
avec moins de 3 bits. 

Le framework Symfony s'appuie par defaut sur l'encodage UTF-8, defini 
dans le fichier de configuration setti ngs . yml de chaque application. 

Configuration de l'encodage par defaut de Symfony dans le fichier apps/frontend/ 
config/settings.yml 

all : 

. setti ngs : 
charset: utf-8 

De plus, par defaut, la couche d'internationalisation de Symfony est 
desactivee afin d'eviter de charger des composants si 1' application n'a pas 
vocation a etre traduite en plusieurs langues. Pour l'activer, il suffit d'agir 
sur la directive de configuration il8n du fichier de configuration 
setti ngs . yml de l'application en placant sa valeur a on. 

Activation de I'internationalisation dans le fichier de configuration apps/frontend/ 
config/settings.yml 

all: 

. setti ngs : 
il8n: on 

Maintenant que l'application est convenablement parametree pour 
accueillir du contenu internationalise, il convient d'etudier les outils 
offerts par Symfony qui permettent de simplifier la traduction de don- 
nees statiques, a commencer par les templates. 



Traduire les contenus statiques des templates 

Les pages web contiennent de nombreux contenus statiques (des mots 
ou des phrases) et dynamiques (des motifs de phrases) qu'il convient de 
traduire. Ces informations sont generalement presentes en dur dans les 
templates mais elles peuvent egalement provenir des classes de modeles 
ou des actions. C'est le cas par exemple des intitules et des messages 
d'erreurs d'un formulaire, ou encore des messages ephemeres qui sont 
affiches en guise de feedback a l'utilisateur apres qu'il a execute une 
action critique. 

Le framework Symfony integre une serie de helpers qui facilitent la tra- 
duction de tous ces types de contenus destines aux templates. Le premier 
et sans doute le principal d'entre eux est la fonction (). 

Utiliser le helper de traduction 0 

Dans un template, toutes les chaines de caracteres qui dependent de la 

langue doivent etre encapsulees avec le helper (), qui s'ecrit seulement 

avec deux tirets soulignes (underscore). Cette fonction fait partie inte- 
grante des helpers du groupe II 8N, qui contient un jeu de helpers destines 
a faciliter la gestion des contenus internationalises dans les templates. 

Charger automatiquement le helper 0 

Le groupe de helpers I18N n'est pas charge par defaut par le framework 
pour des raisons de performance. Le groupe I18N doit done etre charge 
manuellement, soit localement dans chaque template qui en fait usage 
via 1'utilisation du helper use_hel per( ' I18N ' ) qui a ete presente a l'occa- 
sion du chargement des helpers du groupe Text, soit globalement pour 
toute l'application en l'ajoutant a la liste des helpers standards dans la 
directive de configuration standarcLhelpers du fichier de configuration 
settings. yml. 

Ajout du groupe de helpers I18N dans le fichier apps/frontend/config/settings.yml 

all : 

. setti ngs : 

standard helpers: [Partial, Cache, I18N] 

Apres une regeneration du cache de Symfony, toutes les pages de Jobeet 

pourront faire appel au helper (). La section ci-apres montre dans le 

detail comment s'utilise ce helper. 

Traduire les contenus statiques dans les templates 

Le fonctionnement de cette fonction est extremement simple puisqu'il 
s'agit d'afficher tous les contenus statiques a l'aide de ce helper comme le 



Choix de conception Utiliser une chaine 
ou un identifiant unique en guise 
de parametre 

Le helper () accepte en guise de parametre 

aussi bien une phrase de la langue source par 
defaut qu'un identifiant unique pour chaque tra- 
duction. Ceci est en fait une simple question de 
gout pour le developpeur. Dans le cadre de 
Jobeet, c'est la premiere methode qui est uti- 
lised car elle permet de rendre les templates 
bien plus lisibles que la seconde. 



Choix de conception 

Utiliser d'autres types de catalogue 

D'autres catalogues de stockage des traductions 
existent dans Symfony. II s'agit par exemple de 
gettext, MySQL ou SQLite. Comme toujours, il 
suffit de regarder dans la documentation ou 
dans I'API 11 8N pour davantage de details. 



TECHNOLOGIE Le format XLIFF 

XLIFF est I'acronyme de XML Localization 
Interchange File Format. II s'agit d'un format 
standard de donnees reposant sur le format XML 
qui permet de faciliter le stockage des donnees 
visant a etre internationalisms. Le format XLIFF a 
ete standardise en 2002 par I'OASIS, I'organisation 
qui se charge de standardiser les formats de struc- 
turation de I'information pour les domaines de 
I'informatique, du e-business, de la securite, du 
gouvernement, des services web... La specifica- 
tion actuelle de XLIFF etablit les attributs et les 
elements necessaires d'aide a la localisation. 



presente le code ci-dessous. II s'agit ici du pied de page du template du 
layout de l'application de Jobeet dans lequel tous les contenus statiques a 

traduire ont ete encapsules dans un appel a () , au lieu d'etre inscrits 

directement en dur sous forme de donnees HTML brutes. 

Utilisation du helper () dans le fichier apps/frontend/templates/layout.php 

<div id="footer"> 

<div class="content"> 
<span cl ass="symfony"> 

<img src="/images/jobeet-mini .png" /> 

powered by <a href="http://www. symfony-project.org/"> 

<img src="/images/symfony.gif" alt="symfony framework" / 

></a> 

</span> 
<ul> 
<li> 

<a href=""x?php echo ('About Jobeet') ?></a> 

</li> 

<li class="feed"> 

<?php echo "link^toC ('Full feed'), 

'@job?sf_format=atom') ?> 
</li> 
<li> 

<a href=""x?php echo ('Jobeet API') ?></a> 
</li> 

<li class="last"> 

<?php echo link to( ('Become an affiliate'), 

'@affi1iate_new') ?> 
</li> 
</ul> 

<?php include_component(' language' , 'language') ?> 

</di v> 
</di v> 

Lorsque le framework evalue un template, et a chaque fois que le helper 

() est appele, Symfony recherche une traduction pour la culture de 

l'utilisateur courant. Si la traduction est trouvee dans le catalogue, elle 
est renvoyee, sinon c'est la chaine passee en premier argument qui est 
renvoyee a la place. 

Toutes les traductions sont stockees dans un catalogue. Le framework 
d'internationalisation de Symfony fournit differentes strategies pour sau- 
vegarder les traductions. Pour Jobeet, c'est le stockage dans des fichiers 
XLIFF (XML Localization Interchange File Format) qui est choisi dans la 
mesure ou c'est le moyen le plus flexible et le plus couramment employe 
dans les projets Symfony C'est d'ailleurs le format de stockage des traduc- 
tions du generateur de backoffice et de la plupart des plug-ins. 
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Extraire les contenus internationalises vers un catalogue XLIFF 

Lecriture manuelle de catalogues XLIFF est relativement fastidieuse, 
c'est pourquoi le framework Symfony fournit la tache automatique 
il8n: extract pour en simplifier la generation en analysant un a un les 
templates ayant des contenus internationalisables. 

| $ php symfony il8n: extract frontend fr --auto-save 

La tache il8n: extract trouve toutes les chaines de caracteres qui ont 
besoin d'etre traduites en langue francaise (f r) dans 1' application fron- 
tend, puis cree ou met a jour le catalogue correspondant. Loption -- 
auto-save force la tache a sauvegarder dans le catalogue les nouvelles 
chaines internationnalisables quelle trouve. II est egalement possible 
d'utiliser l'option --auto-delete qui supprime du catalogue toutes les 
chaines qui n' existent plus dans les templates. 

Pour Jobeet, le resultat d'execution de cette tache automatique produit le 
fichier XML XLIFF suivant : 

Contenu du fichier XLIFF apps/frontend/il8n/fr/messages.xml 

<?xml version="1.0" encodi ng="UTF-8"?> 
<!D0CTYPE xliff PUBLIC "-//XLIFF//DTD XLIFF//EN" 

"http://www.oasi s-open .org/committees/xl iff/documents/ 
xliff .dtd"> 
<xliff version="1.0"> 

<f i 1 e source-1 anguage="EN"target-1 anguage="f r" 
datatype="plaintext" 

original="messages" date="2008-12-14T12:ll:22Z" 
product-name="messages"> 
<header/> 
<body> 

<trans-unit id="l"> 

<source>About 3obeet</source> 
<target/> 
</trans-unit> 
<trans-unit id="2"> 
<source>Feed</source> 
<target/> 
</trans-unit> 
<trans-unit id="3"> 

<source> Jobeet API</source> 
<target/> 
</trans-unit> 
<trans-unit id="4"> 

<source>Become an aff il iate</source> 
<target/> 
</trans-unit> 
</body> 
</f i 1 e> 
</xl i f f > 



Technology 

Outils d'analyse de fichiers XLIFF 

Comme XLIFF est un format standard, il existe un 
nombre important d'outils capables de simplifier le 
processus de traduction d'une application. C'est le 
cas par exemple du projet libre Java « Open Lan- 
guage Tools » qui integre un editeur de code XLIFF. 



ASTUCE Surcharger les traductions 
a plusieurs niveaux 

XLIFF est un format base sur des fichiers. De ce 
fait, les memes regies de priorite et de fusion 
que celles des autres fichiers de configuration 
de Symfony peuvent lui etre applicables. Les 
fichiers 11 8N peuvent ainsi exister au niveau du 
projet, d'une application ou bien d'un module, 
et ce sont les plus specifiques qui redefinissent 
les traductions presentes aux niveaux globaux. 
Le niveau du module est done prioritaire sur 
celui de I'application, qui lui meme est priori- 
taire sur celui du projet. 



Chaque traduction est geree par une balise <trans-unit> qui dispose 
obligatoirement d'un attribut id en guise d'identifiant unique. II suffit 
alors d'aj outer manuellement toutes les traductions pour la langue fran- 
chise a l'interieur de chaque balise <target> correspondante. Ainsi, cela 
conduit a un fichier tel que celui ci-dessous. 

Contenu du fichier XLIFF apps/frontend/il8n/fr/messages.xml 

<?xmT version="1.0" encodi ng="UTF-8"?> 
<!D0CTYPE xTiff PUBLIC "-//XLIFF//DTD XLIFF//EN" 

"http : //www. oasis -open .org/commi ttees/xl iff/documents/ 
xliff .dtd"> 
<xTiff version="1.0"> 

<fiTe source-T anguage="EN" target-T anguage="f r" 
datatype="pT ai ntext" 

originaWmessages" date="2008-12-14T12 : 11: 22Z" 
product- name="messages"> 
<header/> 
<body> 

<trans-unit id="l"> 

<source>About Jobeet</source> 
<target>A propos de Jobeet</target> 
</trans-uni t> 
<trans-unit id="2"> 
<source>Feed</source> 
<target>Fil RSS</target> 
</trans-unit> 
<trans-um't id="3"> 

<source>Jobeet API</source> 
<target>API Dobeet</target> 
</trans-uni t> 
<trans-unit id="4"> 

<source>Become an affi 1 i ate</source> 
<target>Devenir un aff il ie</target> 
</trans-unit> 
</body> 
</f i T e> 
: </xTiff> 

La section suivante aborde un nouveau point interessant du processus de 
traduction. II s'agit des contenus dynamiques. En effet, seuls les con- 
tenus statiques ont ete traduits pour l'instant mais il est aussi frequent 
d'avoir a traduire des contenus qui integrent des valeurs dynamiques. 

Traduire des contenus dynamiques 

Le principe global sous-jacent de l'internationalisation est de traduire 
des phrases entieres, comme cela a ete explique plus haut. Cependant, il 
est frequent d'avoir a traduire des phrases qui embarquent des valeurs 
dynamiques et qui reposent sur un motif particulier. Par exemple, 
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lorsqu'il s'agit d'afficher un nombre au milieu d'une chaine internationa- 
lisable telle que « il y a 10 personnes connectees au site ». 

Le cas des chames dynamiques simples 

Dans Jobeet, c'est aussi le cas avec la page d'accueil qui inclut un lien 
« more... » dont l'affichage final ressemble au motif suivant : « and 12 
more... ». Le code ci-dessous est l'implementation actuelle de ce lien 
dans Jobeet. 

Extrait du contenu du fichier apps/frontend/modules/job/templates/indexSuccess.php 

<div cl ass="more_jobs"> 

and <?php echo 1 i nk_to($count , 'category', Scategory) ?> 
more . . . 
</di v> 

Le nombre d'offres d'emploi est une variable qui devrait etre remplacee 
par un emplacement {placeholder) pour en simplifier sa traduction. Le 
framework Symfony supporte ce type de phrases composees de valeurs 
dynamiques comme le montre le code ci-dessous. 

Extrait du contenu du fichier apps/frontend/modules/job/templates/indexSuccess.php 

<div cl ass="more_jobs"> 

<?php echo ('and %count% more...', array( '%count%' => 

"link to($count, 'category', Scategory))) ?> 

</di v> 

La chaine a traduire est a present « and %count% more. . . », etl'emplace- 
ment %count% sera remplace automatiquement par le nombre reel 
d'offres supplementaires a l'instant t, grace au second parametre facul- 

tatif du helper (). II ne reste finalement qua ajouter cette nouvelle 

chaine a traduire au catalogue de traductions francaises, soit en l'ajoutant 
manuellement dans le fichier messages. xml, soit en reexecutant la tache 
i 18n : extract pour le mettre a jour automatiquement. 

| $ php symfony il8n: extract frontend fr --auto-save 

Apres execution de cette commande, le fichier XLIFF accueille une 
nouvelle traduction pour cette chaine dont le motif est le suivant : 

<trans-unit id="5"> 

<source>and %count% more. . . </source> 
<target>et %count% autres. . .</target> 

</trans-unit> 

La seule obligation dans la chaine traduite est de reutiliser l'emplace- 
ment %count%. 



Traduire des contenus pluriels a partir du helper 
format_number_choiceO 

D'autres contenus internationalisables sont un peu plus complexes dans 
la mesure oil ils impliquent des pluriels. D'apres la valeur de certains 
nombres, la phrase change, mais pas necessairement de la meme maniere 
pour toutes les langues. Certaines langues comme le russe ou le polonais 
ont des regies de grammaire tres complexes pour gerer les pluriels. Sur la 
page de detail d'une categorie, le nombre d'offres dans la categorie cou- 
rante est affiche de la maniere suivante. 

<strongx?php echo $pager->getNbResul ts() ?></strong> jobs in 
this category 

Lorsqu'une phrase possede differentes traductions en fonction d'un 
nombre, le helper format_number_choiceO prend le relais pour prendre 
en charge la bonne traduction a afficher. 

<?php echo format_number_choi ce( 

'[0]No job in this category | [l]One job in this 
category | (l,+Inf]%count% jobs in this category', 

array('%count%' => '<strong>' .$pager->getNbResults() . '</ 
strong>') , 

$pager->getNbResu"l ts() 

) 

?> 

Le helper format_number_choice accepte trois arguments : 

• la chaine a afficher qui depend du nombre ; 

• un tableau des valeurs des emplacements a remplacer ; 

• le nombre a tester pour determiner quelle traduction afficher. 

La chaine qui decrit les differentes traductions en fonction du nombre 
est formatee de la maniere suivante : 

• chaque possibilite est separee par un caractere pipe ( | ) ; 

• chaque chaine est composee d'un intervalle de valeurs numeraires 
suivi par la traduction elle-meme. 

Lintervalle peut decrire n'importe quel type de suite ou d'intervalle de 
nombres : 

• [1,2] : accepte toutes les valeurs comprises entre 1 et 2, bornes 
incluses ; 

• (1,2) : accepte toutes les valeurs comprises entre 1 et 2, bornes 
exclues ; 

• {1,2,3,4}: accepte uniquement les valeurs definies dans cet 
ensemble ; 



• [-Inf , 0) : accepte les valeurs superieures ou egales a l'infini negatif et 
strictement inferieures a 0 ; 

• {n: n % 10 > 1 && n % 10 < 5} : correspond aux nombres comme 2, 
3, 4, 22, 23, 24. 

Traduire ce type de chaine est similaire aux autres messages de 
traduction : 

<trans-unit id="6"> 

<source>[0]No job in this category | [l]One job in this 
category | (l,+Inf]%count% jobs in this category</source> 

<target>[0]Aucune annonce dans cette categorie | [l]Une annonce 
dans cette categorie| (l,+Inf]%count% annonces dans cette 
categorie</target> 
</trans-unit> 

Maintenant que tous les moyens de traduction des chaines statiques et 
dynamiques ont ete presentes, il ne reste plus qua prendre le temps pour 

apprehender le helper () en traduisant tous les messages de l'applica- 

tion frontend. Pour la suite de ce chapitre, 1' application backend ne sera 
pas internationalisee. 



Traduire les contenus propres aux formulaires 

Les classes de formulaire contiennent plusieurs chaines qui ont besoin 
d'etre traduites comme les intitules des champs, les messages d'erreurs et 
les messages d'aide. Heureusement, toutes ces chaines sont automati- 
quement internationalisees par Symfony Par consequent, il suffit uni- 
quement de specifier les traductions dans le fichier XLIFF. 



A RETENIR Limites de la tache automatique 
i18n:extract 

Malheureusement, la commande 

il8n: extract a ses limites puisqu'elle n'ana- 
lyse pas encore les classes de formulaire a la 
recherche de chaines non traduites. 



Activer la traduction des objets Doctrine 

L'un des sujets les plus delicats a traiter lorsqu'on manipule des donnees 
internationalisables dans une application dynamique concerne bien evidem- 
ment les enregistrements de la base de donnees. Dans cette section, il s'agit 
de decouvrir de quelle maniere le framework Symfony et l'ORM Doctrine 
simplifient la gestion des contenus internationalises en base de donnees. 

Pour l'application Jobeet, il ne sera pas utile d'internationaliser toutes les 
tables dans la mesure ou cela n'a pas de veritable sens de demander aux 
auteurs d'offres de traduire leurs propres annonces. Neanmoins, la tra- 
duction de la table des categories semble legitime. 
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Internationaliser le modele JobeetCategory de la base 

Le plug-in Doctrine supporte nativement les tables d'internationalisa- 
tion. Pour chaque table qui contient des donnees regionalisees, deux 
tables sont finalement necessaires. En effet, la premiere stocke les 
valeurs independantes de TI18N pour l'enregistrement donne, tandis que 
la seconde sert a conserver les valeurs des champs internationalises de ce 
meme enregistrement. Les deux tables sont reliees entre elles par une 
relation dite « one-to-many ». 

L'internationalisation de la table des categories necessite de mettre a jour 
le modele JobeetCategory comme le montre le schema ci-dessous. 

Ajout du comportement I18N au modele JobeetCategory dans le fichier config/ 
doctrine/schema.yml 

JobeetCategory: 
actAs : 

Timestampable: ~ 
I18n: 

fields: [name] 
actAs: 

Sluggable: { fields: [name], uniqueBy: [lang, name] } 

col umns : 

name: { type: string(255), notnull : true } 

En activant le comportement I18n, un nouveau modele intitule 
JobeetCategoryTranslation sera automatiquement cree et les champs 
localisables seront deplaces vers ce modele. De plus, il faut remarquer 
que le comportement SI uggabl e a ete deporte vers le modele d'interna- 
tionalisation JobeetCategoryTranslation. L'option uniqueBy indique au 
comportement Sluggable quels champs determinent si un slug est 
unique ou non. Dans le cas present, il s'agit de rendre unique chaque 
paire langue/slug. 

Mettre a jour les donnees initiales de test 

Avant de reconstruire tout le modele, il convient de mettre a jour les 
donnees initiales de Implication puisque le champ name d'une categorie 
n'appartient plus directement au modele JobeetCategory mais a l'objet 
JobeetCategoryTranslation. Le code ci-dessous donne le contenu du 
fichier de donnees initiales des categories qui seront rechargees en base 
de donnees a la reconstruction de tout le modele. 



Contenu du fichier data/fixtures/categories.yml 

DobeetCategory : 
desi gn : 

Translation: 
en: 

name: Design 
fr: 

name: design 
programmi ng : 
Translation: 
en: 

name: Programming 
fr: 

name: Programmation 
manager: 

Translation: 
en: 

name: Manager 
fr: 

name: Manager 

admi ni strator: 
Translation: 
en: 

name: Administrator 
fr: 

name: Administrateur 

Surcharger la methode findOneBySlugO du modele 
JobeetCategoryTable 

La methode fi ndOneBySl ug() de la classe JobeetCategoryTable doit etre 
redefinie. En effet, depuis que Doctrine fournit quelques finders magi- 
ques pour chaque colonne d'un modele, il suffit de creer une methode 
findOneBySlugO qui surcharge le comportement initial du finder Doc- 
trine. Pour ce faire, cette methode doit arborer quelques changements 
supplementaires afin que la categorie soit retrouvee a partir du slug 
anglais present dans la table JobeetCategoryTranslation. 

Implementation de la methode findOneBySlugO dans le fichier lib/model/doctrine/ 
JobeetCategoryTable.cass.php 

public function fi ndOneBySl ug($sl ug) 
{ 

$q = $this->createQuery('a') 
->leftJoin('a. Translation t') 
->andWhere('t.1ang = ?' , 'en') 
->andWhere('t.slug = ?' , $s"lug); 

return $q->f etchOneO ; 

} 



A RETENIR La tache doctrine:build-all-reload 

Comme la commande doctri ne : bui 1 d- 
all- reload supprime toutes les tables et don- 
nees de la base de donnees, il ne faut pas oublier de 
recreer un utilisateur pour acceder a I'espace 
d'administration de Jobeet a I'aide de la tache 
guard : create-user presentee dans les cha- 
pitres precedents. Alternativement, il paratt aussi 
astucieux d'ajouter un fichier de donnees initiales 
contenant les informations de I'utilisateur qui seront 
automatiquement chargees en base de donnees. 



La prochaine etape consiste a present a reconstruire tout le modele a 
I'aide de la tache automatique doctrine: bui Id-all. 

$ php symfony doctrine: bui ld-all --no-confirmation 
$ php symfony cc 

Methodes raccourcies du comportement I18N 

Lorsque le comportement I18N est attache a une classe de modele 
comme celle des categories par exemple, des methodes raccourcies (dites 
« proxies ») entre l'objet JobeetCategory et les objets 
JobeetCategoryTranslation associes sont creees. Grace a elles, les 
anciennes methodes pour retrouver le nom de la categorie continuent de 
fonctionner en se fondant sur la valeur de la culture courante. 

: Scategory = new JobeetCategoryO ; 
$category->setName('foo') ; // definit le nom pour la culture 
courante 

$category->getName() ; // retourne le nom pour la culture 
courante 

$this->getUser()->setCulture('fr') ; // depuis une classe 
d' actions 

; $category->setName('foo') ; // definit le nom en francais 
echo $category->getName() ; // retourne le nom en francais 

Pour reduire le nombre de requetes a la base de donnees, il convient de 
joindre la table JobeetCategoryTranslation dans les requetes SQL. Cela 
permettra de recuperer l'objet principal et ses informations internationa- 
lisees en une seule requete. 

Scategories = Doctrine_Query: :create() 
->from( ' JobeetCategory c') 

->left3oin('c. Translation t WITH t.lang = ?', $culture) 

->execute() ; 

Le mot-cle WITH ci-dessus ajoutera automatiquement la condition a la 
clause ON de la requete SQL, ce qui se traduit au final par la requete SQL 
suivante : 

| LEFT JOIN c. Translation t ON c.id = t.id AND t.lang = ? 

Mettre a jour le modele et la route de la categorie 

Puisque d'une part la route qui mene a la categorie est liee au modele 
JobeetCategory, et que d'autre part le slug est maintenant un champ de 
la table JobeetCategoryTranslation, la route n'est plus capable de 
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retrouver l'objet category automatiquement. Pour aider le systeme de 
routage de Symfony, une nouvelle methode doit etre ajoutee au modele 
afin de se charger de la recuperation de l'objet. 

Implementer la methode findOneBySlugAndCultureO du modele 
JobeetCategoryTable 

La methode f i ndOneBySl ug () a deja ete redefinie plus haut, mais a voca- 
tion a etre factorisee davantage afin que les nouvelles methodes puissent 
etre partagees. L'objectif est de creer deux nouvelles methodes 
findOneBySlugAndCultureO et doSelectForSlugO, puis de changer 
fi ndOneBySl ug() pour utiliser simplement la methode 
f i ndOneBySl ugAndCul tu re (). 

Implementation des nouvelles methodes dans la classe JobeetCategoryTable du 
fichier lib/model/doctrine/JobeetCategoryTable.class.php 

public function doSelectForSlug($parameters) 
{ 

return $thi s->fi ndOneBySl ugAndCul ture($parameters [' si ug ' ] , 
$parameters['sf„culture']) ; 
} 

public function fi ndOneBySl ugAndCul ture($sl ug , Sculture = 'en') 
{ 

$q = $this->createQuery('a') 

->1eftDoin('a. Translation t') 

->andWhere('t.1ang = ?' , $culture) 

->andWhere('t.slug = ?' , $s"lug); 
return $q->fetchOne() ; 

} 

public function fi ndOneBySl ug($sl ug) 
{ 

return $thi s->fi ndOneBySl ugAndCul ture($sl ug , 'en'); 

} 

// ... 



Mise a jour de la route category de 1'application frontend 

Les methodes de la classe JobeetCategoryTable sont maintenant ideale- 
ment factorisees, ce qui permet desormais a la route de retrouver l'objet 
JobeetCategory auquel elle est liee. Pour ce faire, l'option method de la 
route Doctrine doit etre editee pour lui indiquer quelle aura recours a la 
methode getForSlugO pour recuperer l'objet associe. 



Route category du fichier apps/frontend/config/routing.yml 



category: 

url : /:sf culture/category/: slug. :sf_format 

class: sfDoctri neRoute 

param: { module: category, action: show, sf_format: html } 
options: { model: JobeetCategory , type: object, method: 
doSelectForSlug } 
requi rements : 

sf_format : (? : html | atom) 

Pour finir, les donnees initiales doivent etre renouvelees dans la base de 
donnees afin de regenerer les champs internationalises. 

| $ php symfony doctrine: data-load 

La route category est desormais entierement internationalisee et 
embarque les slugs appropries en fonction de la langue du site. 

/f rontend_dev. php/f r/category/programmation 
/frontend_dev. php/en/category/prog ramming 

Champs internationalises dans un formulaire Doctrine 

Internationaliser le formulaire d'edition d'une categorie dans le 
backoffice 

Suite a tous les ajustements qui ont ete operes jusqu'a present, les cate- 
gories sont desormais entierement internationalisees mais ne beneficient 
pas encore d'un moyen pour gerer l'ensemble des champs traduits. 
L'interface d'administration actuelle permet uniquement d'editer les 
champs d'une categorie correspondante a la culture de l'utilisateur. Or, il 
parait pertinent de permettre a l'administrateur du site d'agir sur 
l'ensemble des champs internationalises du formulaire en une seule passe 
comme cela figure sur la capture d'ecran ci-contre. 

Utiliser la methode embedll8n() de I'objet sfFormDoctrine 

Tous les formulaires Doctrine supportent nativement les relations avec 
les tables d'internationalisation des objets qu'ils permettent de mani- 
puler. En effet, I'objet sfFormDoctrine dispose de la methode 
embedI18n() qui ajoute automatiquement le controle de tous les champs 
internationalisables d'un objet. Son usage est extremement simple 
puisqu'il s'agit de l'appeler dans la methode configureO du formulaire 
en lui passant en parametre un tableau des cultures a integrer au formu- 
laire. Le code ci-dessous correspond a la classe de formulaire 
JobeetCategoryForm qui fait appel a cette methode pour afficher les 
champs traduits pour les langues francaise et anglaise. 



Jobeet 



lobs Affiliates - 1 Categories Users Logout 
EDIT CATEGORY 

English 



Name 




Programming 


Slug 




programming 



French 



Name 




Programmation 


Slug 




programmation 



X Delete □ Cancel (Save) 

Figure 18-2 Formulaire d'edition des champs internationalises d'une categorie 

Implementation de la methode embedll8n() dans la classe JobeetCategoryForm du 
fichier lib/form/JobeetCategoryForm.class.php 

class JobeetCategoryForm extends BaseJobeetCategoryForm 
{ 

public function configure() 
{ 

unset( 

$thi s [ ' jobeet_af f i 1 i atesjl i st ' ] , 

$thi s [ ' created_at ' ] , $thi s [ ' updated_at ' ] 

); 

$this->embedI18n(array('en' , 'fr')); 
$this->widgetSchema->setLabel ('en' , 'English') ; 
$this->widgetSchema->setLabel ('fr' , 'French') ; 

} 

} 

Internationalisation de I'interface du generateur d'administration 

L'interface issue du generateur d'administration supporte nativement 
l'internationalisation. Le framework Symfony est livre avec les fichiers 
de traduction XLIFF de l'interface d'administration dans plus de vingt 
langues differentes grace a l'effort de la communaute. II est done desor- 
mais tres facile d'aj outer de nouvelles traductions ou bien de personna- 
liser les intitules existants. 
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A RETENIR Supprimer les squelettes de 
f ichiers de tests autogeneres 

Lorsque I'interface d'administration de Jobeet a ete 
developpee, aucun test fonctionnel n'a ete ecrit. 
Neanmoins, a chaque fois qu'un nouveau module 
est genere a I'aide de la ligne de commande de 
Symfony, le framework en profite pour creer des 
squelettes de fichiers de tests. Ces derniers peuvent 
etre supprimes du projet en toute securite. 



Pour y parvenir, il suffit de copier le fichier des traductions de la langue a 
personnaliser dans le repertoire il8n/ de l'application. Les fichiers de 
traduction de Symfony pour le plug-in sf Doctri nePl ugi n se situent dans 
le repertoire 1 i b/vendor/symf ony/1 i b/pl ugi ns/sf Doctri nePl ugi n/i 18n/ 
du projet Jobeet. Comme le fichier de l'application est fusionne avec 
celui de Symfony, il suffit de garder uniquement les traductions modi- 
flees dans le nouveau fichier de traduction. 

Forcer ('utilisation d'un autre catalogue de traductions 

II est interessant de remarquer que les fichiers de traduction du genera- 
teur d'interface d'administration sont nommes suivant le format 
sf_admin.fr.xml, au lieu de f r/messages . xml . En fait, messages est le 
nom du catalogue utilise par defaut dans Symfony mais il peut bien sur 
etre modifie afin de permettre une meilleure separation des differentes 
parties de l'application. Utiliser un catalogue specifique plutot que celui 

par defaut necessite de l'indiquer explicitement au helper () a I'aide de 

son troisieme argument facultatif. 

| <?php echo ('About Jobeet', arrayO, 'jobeet') ?> 

Dans l'appel au helper () ci-dessus, Symfony cherchera la chaine 

« About Jobeet » dans le catalogue jobeet. 

Tester l'application pour valider le processus de 
migration de PI18N 

Corriger les tests fonctionnels fait partie integrante du processus de 
migration vers une interface internationalisee. Dans un premier temps, 
les fichiers de donnees de tests pour les categories doivent etre mis a jour 
en recuperant celles qui se trouvent dans le fichier test/fixtures/ 
categories. yml. Puis l'integralite du modele et de la base de donnees de 
test doit a son tour etre regeneree pour prendre en compte toutes les 
modifications realisees jusqu'a present. 

$ php symfony doctrine:bui1d-a11-reload --no-confirmation 
— env=test 

Enfin, l'execution de toute la suite de tests unitaires et fonctionnels indi- 
quera si l'application se comporte toujours aussi bien ou non. Si des tests 
echouent, c'est qu'une regression a probablement ete engendree quelque 
part lors du processus de migration. 

$ php symfony test: all 
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Decouvrir les outils de localisation de Symfony 

La fin de ce chapitre arrive pratiquement a son terme et il reste pourtant 
un point important qui n'a pas encore ete traite dans le processus d'inter- 
nationalisation d'une application web : la localisation. En effet, la locali- 
sation est la partie de 1'internationalisation relative a toutes les questions 
de formatage de donnees propres a la region de l'utilisateur comme les 
nombres, les dates, les heures ou bien encore les devises monetaires. 

Regionaliser les formats de donnees dans les templates 

Supporter differentes langues signifie aussi supporter differentes 
manieres de formater les dates et les nombres. Pour les templates, le fra- 
mework Symfony met a disposition un jeu de helpers qui permettent 
d'aider a prendre en compte toutes ces differences relatives a la culture 
courante de l'utilisateur. 

Les helpers du groupe Date 

Le groupe de helpers Date fournit cinq fonctions pour assurer le forma- 
tage des dates et des heures dans les templates. 



Tableau 18-1 Liste des fonctions de formatage de dates et heures du groupe de helpers Date 





format_date() 


Formate une date 


f ormat_dateti me () 


Formate une date et le temps (heures, minutes, secondes...) 


time_ago_i n_words() 


Affiche le temps passe depuis une date jusqu'a maintenant en toutes lettres 


di stance_of_ti me_i n_words () 


Affiche le temps passe entre deux dates en toutes lettres 


f o rmat_date range () 


Formate un intervalle de dates 



Le detail de ces helpers est disponible dans l'API de Symfony a 
l'adresse : http://www.symfony-project.org/api/1_2/DateHelper 



Les helpers du groupe Number 

Le groupe de helpers Number fournit deux fonctions pour assurer le for- 
matage des nombres et devises dans les templates. 



Tableau 18-2 Liste des fonctions de formatage de nombres et devises du groupe de helpers Number 







Description 


format_number() 


Formate un nombre 


f ormat_cu r rency () 


Formate une devise monetaire 



Le detail de ces helpers est disponible dans l'API de Symfony a 
l'adresse : http://www.symfony-project.org/api/1_2/NumberHelper 



Les helpers du groupe U8N 

Le groupe de helpers I18N fournit deux fonctions pour assurer le forma- 
tage des noms de pays et langues dans les templates. 



Tableau 18-3 Liste des fonctions de formatage des noms de pays 
et langues du groupe de helpers 11 8N 



Nom du helper 


Description 


format_countryO 


Affiche le nom d'un pays 


formaOanguageO 


Affiche le nom d'une langue 



Le detail de ces helpers est disponible dans l'API de Symfony a 
l'adresse : http://www.symfony-project.org/api/1_2/H8NHelper 



Regionaliser les formats de donnees dans les 
formulaires 

Le framework de formulaires de Symfony fournit egalement plusieurs 
widgets et validateurs pour gerer les differentes donnees localisees. Le 
tableau ci-apres donne le nom ainsi qu'une description de chacun d'eux. 

Tableau 18-4 Widgets et validateurs de donnees localisees dans les formulaires 



sfWf dgetFormI18nDate 


Genere un widget de saisie de date 


sfWi dgetFormI18nDateTi me 


Genere un widget de saisie de date et de 
temps 


sfWi dgetFormI18nTime 


Genere un widget de saisie de temps 


sfWf dgetFormI18nSef ectCountry 


Genere une liste deroulante de pays 


sfWi dgetFormI18nSef ectCurrency 


Genere une liste deroulante de devises 
monetaires 


sfWf dgetFormI18nSef ectLanguage 


Genere une liste deroulante de langues 


sfVal i datorI18nChoi ceCountry 


Valide la valeur d'un pays 


sfVal i datorI18nChoi ceLanguage 


Valide la valeur d'une langue 



En resume 



L'internationalisation et la localisation sont des concepts parfaitement 
integres dans Symfony. Le processus d'internationalisation d'un site 
Internet a destination des utilisateurs est extremement aise dans la mesure 
oil Symfony fournit tous les outils necessaires ainsi qu'une interface en 
ligne de commande pour en accelerer le developpement. 

Ce chapitre a permis de decouvrir 1'ensemble des outils qu'offre Sym- 
fony pour simplifier l'internationalisation d'une application. Ce large 
panel d'outils comprend a la fois des catalogues de traduction XLIFF et 
de nombreux jeux de helpers pour formater des donnees (nombres, dates, 
heures, langues, devises monetaires...), traduire des contenus textuels 
statiques et dynamiques ou encore de gerer les pluriels. 

Avec l'integration de l'ORM Doctrine, l'internationalisation des objets en 
base de donnees est grandement facilitee puisque Symfony et Doctrine 
fournissent les APIs adequates pour prendre automatiquement en charge 
la manipulation des donnees a traduire, notamment lorsqu'il s'agit de les 
manipuler par le biais des formulaires. 

Le chapitre suivant est un peu special puisqu'il y est question de deplacer 
la plupart des fichiers de Jobeet a i'interieur de plug-ins personnalises. 
Les plug-ins constituent en effet une approche differente pour organiser 
un projet Symfony Ces prochaines pages seront done l'occasion de 
decouvrir 1'ensemble des multiples avantages qu'offre une telle approche 
organisationnelle. . . 



chapitre 




Structure par defaut 



Architecture d'un plugin 



apps/ 
frontend/ 
config/ 
routing. yml 

il8n/ 

modules/ 
job/ 
config/ 

schema. yml 
lib/ 
filter/ 
form/ 
model/ 
task/ 
web/ 




plugins/ 
sf JobeetPlugin/ 
config/ 
— ^ routing. yml 
schema. yml 
il8n/ 
lib/ 
filter/ 
form/ 
model/ 
task/ 
modules/ 

sf JobeetDob/ 
web/ 



Les plug-ins 




MOTS-CLES 



Le framework Symfony beneficie d'une communaute qui 
contribue activement au developpement du projet a travers 
la creation et la publication de plug-ins. Les plug-ins sont 
des unites fonctionnelles independantes du projet 
qui remplissent des besoins specifiques (authentification, 
traitement d'images, API de manipulation d'un service web. . .) 
afin d'empecher le developpeur de reinventer une nouvelle fois 
la roue et d'accelerer la mise en place de son projet. 



► Plug-ins 

► Internationalisation 

► Routage 



Le chapitre precedent a aborde dans son integralite le vaste sujet de 
l'internationalisation et de la localisation d'une application web. Ces 
deux concepts sont nativement supportes a tous les niveaux (base de 
donnees, routage, catalogue de traductions...) grace aux nombreux outils 
qu'offre le framework Symfony. Aborder ce sujet fut egalement l'occa- 
sion d'installer le plug-in sfFormExtraPlugin et d'en decouvrir certaines 
fonctionnalites. Ce dix-neuvieme chapitre s'interesse tout particuliere- 
ment aux plug-ins : ce qu'ils sont, a quoi ils servent, comment les deve- 
lopper et les diffuser sur le site Internet de Symfony... 



Qu'est-ce qu'un plug-in dans Symfony ? 



Les plug-ins Symfony 

Un plug-in Symfony offre une maniere differente de centraliser et de 
distribuer un sous-ensemble des fichiers d'un projet. Au meme titre 
qu'un projet, un plug-in est capable d'embarquer des classes, des helpers, 
des fichiers de configuration, des taches automatisees, des modules fonc- 
tionnels, des schemas de description d'un modele de donnees, ou encore 
des ressources pour le web (feuilles de style en cascade, JavaScripts, ani- 
mations Flash...). 

Une section prochaine de ce chapitre revelera qu'en fait, un plug-in est 
structure quasiment de la meme maniere qu'un projet, voire une applica- 
tion. En somme, un plug-in peut aussi bien transporter uniquement un jeu 
restreint de fichiers (des classes par exemple) qu'embarquer une application 
fonctionnelle complete comme un forum de discussion ou un CMS. 



Astuce 

Installer ses propres plug-ins prives 

La tache automatique pi ugi n : i nstal 1 est 
capable d'installer des plug-ins prives a condition 
que ces derniers aient ete realises comme il se doit, 
et qu'un canal prive de plug-ins ait ete ouvert. 



Les plug-ins prives 

Le premier usage des plug-ins est avant tout de faciliter le partage de 
code entre les applications, et dans le meilleur des cas, entre les projets. 
II est important de se rappeler que les applications Symfony d'un meme 
projet ne partagent que le modele et quelques classes et fichiers de confi- 
guration. Les plug-ins, quant a eux, fournissent un moyen de partager 
davantage de composants entre les applications. 

Lorsque nait le besoin de reutiliser le meme schema de donnees pour diffe- 
rents projets, ou pour les memes modules, cela signifie qu'il est preferable de 
le deplacer vers un plug-in. En pratique, un plug-in n'est finalement qu'un 
simple repertoire ; c'est pour cette raison qu'il devient alors possible de 
rexternaliser aussi facilement, par exemple en creant un depot SVN dedie 
ou simplement en copiant les fichiers d'un projet dans un autre. 
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On les appelle « plug-ins prives » parce que leur usage est restreint et 
specifique a un seul developpeur, une application ou bien encore une 
societe. Par consequent, ils ne sont pas disponibles publiquement. 

Les plug-ins publics 

Les plug-ins publics sont mis gratuitement a disposition de la commu- 
naute qui peut alors les telecharger, les installer et les utiliser librement. 
C'est d'ailleurs ce qui a ete realise jusqu'a maintenant puisqu'une partie 
des fonctionnalites de l'application Jobeet repose sur les deux plug-ins 
publics sfDoctrineGuardPlugin et sf FormExtraPI ugi n. 

Les plug-ins publics sont exactement identiques aux plug-ins prives au 
niveau de leur structure. La seule difference qui les oppose est que 
n'importe qui peut installer ces plug-ins publics dans ses propres projets. 
Une partie de ce chapitre se consacre d'ailleurs a presenter comment 
publier et heberger un plug-in public sur le site officiel de Symfony. 

Une autre maniere d'organiser le code du projet 

II existe encore une maniere supplemental de penser aux plug-ins et de 
les utiliser. Cette fois-ci, il ne s'agit pas de reflechir en termes de partage et 
de reutilisation mais en termes d' organisation et d'architecture. En effet, 
les plug-ins peuvent egalement etre percus comme une maniere totale- 
ment differente d'organiser le code d'un projet. Au lieu de structurer les 
fichiers par couches - tous les modeles dans le repertoire 1 i b/model par 
exemple - les fichiers sont organises par fonctionnalites. Par exemple, tous 
les fichiers propres aux offres d'emploi seront regroupes (le modele, les 
modules et les templates), tous les fichiers d'un CMS egalement, etc. 

Decouvrir la structure de fichiers d'un plug-in Symfony 

Plus concretement, un plug-in est avant tout une architecture de reper- 
toires et de fichiers qui sont organises d'apres une structure predefinie, 
en fonction de la nature des fichiers qu'il contient. Lobjectif de ce cha- 
pitre est de deplacer la plupart du code de Jobeet ecrit jusqu'a present 
dans un plug-in dedie sfJobeetPlugin. La structure finale de ce plug-in 
correspondra a celle presentee ci-dessous. 



sf JobeetPl ugi n/ 
config/ 

sf JobeetPl ugi nConf i gu rati on . 
routing, yml 
doctrine/ 
schema. yml 

lib/ 

Jobeet. class. php 
hel per/ 
filter/ 
form/ 
model/ 
task/ 
modules/ 
job/ 

actions/ 

confi g/ 

templates/ 

web/ 
and images 



.php // PI ugi n initialization 
// Routing 

// Database schema 

// Classes 

// Helpers 

// Filter classes 

// Form classes 

// Model classes 

// Tasks 

// Modules 



// Assets like JS, CSS, 



freer le plug-in sfJobeetPlugin 



Convention 

Nommage des noms des plug-ins 

Une convention de nommage impose que les noms 
des plug-ins doivent se terminer par le suffixe 
PI ugi n. D'autre part, une bonne pratique con- 
siste egalement a prefixer les noms de plug-ins 
avec sf, bien que ce ne soit pas une obligation. 



II est temps de se consacrer a la creation du plug-in sfJobeetPlugin. 
Etant donne que 1' application Jobeet contient de nombreux fichiers a 
deplacer, le processus de creation du plug-in se deroulera en sept etapes 
majeures successives : 

1 deplacement des fichiers du modele ; 

2 deplacement des fichiers du controleur et de la vue ; 

3 deplacement des taches automatisees ; 

4 deplacement des fichiers d'internationalisation de Jobeet ; 

5 deplacement du fichier de configuration dedie au routing ; 

6 deplacement des fichiers des ressources web ; 

7 deplacement des fichiers de l'utilisateur. 

Bien entendu, ce processus ne se limite pas seulement a deplacer des 
fichiers et des dossiers. Certaines parties du code devront etre actualisees 
pour prendre en consideration ce changement majeur de l'architecture 
de Jobeet. 

Avant de demarrer le premier point de cette liste d'etapes, le repertoire 
dedie au plug-in doit etre cree dans le projet sous le repertoire plugins/. 



| $ mkdir pi ugi ns/sf JobeetPl ugi n 
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Migrer les fichiers du modele vers le plug-in 



Deplacer le schema de description de la base 

La premiere etape du processus de migration vers un plug-in consiste a 
deplacer tous les fichiers concernant le modele. C'est l'une des phases les 
plus critiques car elle necessite de toucher au code du modele par 
endroits, comme il est explique plus loin. Pour commencer, il convient 
de bouger le schema de description du modele de Jobeet dans le plug-in. 

$ mkdi r plugins/sf JobeetPlugin/config/ 

$ mkdi r plugins/sf JobeetPlugin/config/doctrine 

$ mv config/doctrine/schema.yml plugins/sfJobeetPlugin/config/ 

doctr i ne/schema . yml 

Deplacer les classes du modele, de formulaires et de filtres 

Apres cela, le plug-in doit accueillir l'ensemble des fichiers du modele 
comprenant les classes du modele, les classes de formulaires ainsi que les 
classes de filtres. II faut done commencer par creer un repertoire 1 i b/ a 
la racine du repertoire du plug-in, puis deplacer a l'interieur les reper- 
toires lib/model, lib/form et lib/filter du projet. 

$ mkdi r pi ugi ns/sf JobeetPl ugi n/1 i b/ 

$ mv lib/model/ pi ugi ns/sf JobeetPl ugi n/lib/ 

$ mv lib/form/ pi ugi ns/sf JobeetPl ugi n/1 i b/ 

$ mv lib/filter/ pi ugi ns/sf JobeetPl ugi n/1 i b/ 



RAPPEL 

Manipulation des fichiers d'un projet 

Toutes les commandes presentees dans ce chapitre 
sont relatives aux environnements Unix. Pour les 
environnements Windows, il suffit de creer 
manuellement les fichiers, puis de les glisser et de 
les deposer a partir de I'explorateur de fichiers. 
Pour les developpeurs qui utilisent Subversion ou 
d'autres outils de gestion du code, il est necessaire 
d'avoir recours aux outils que ces logiciels fournis- 
sent comme la commande svn mv de Subversion 
pour deplacer les fichiers versionnes d'un depot. 



Transformer les classes concretes en classes abstraites 

Apres avoir deplace les classes du modele, de formulaires, et de filtres, celles- 
ci doivent etre renommees et declarees abstraites en prenant garde a les pre- 
frxer avec le mot PI ugi n. Les exemples qui suivent montrent comment 
deplacer les nouvelles classes abstraites et les modifier en consequence. 

Void un exemple de marche a suivre pour deplacer les classes 
JobeetAffiliate et JobeetAffiliateTable afin qu'elles deviennent abs- 
traites et puissent etre derivees automatiquement par les nouvelles 
classes concretes que Doctrine regenerera a la prochaine reconstruction 
du modele. 

$ mv plugins/sfJobeetPlugin/lib/model/doctrine/ 

JobeetAf f i 1 i ate . cl ass . php pi ugi ns/sf JobeetPl ugi n/1 i b/model / 

doctri ne/Pl ugi nJobeetAf f i 1 i ate . cl ass . php 

La definition du nom de la classe JobeetAffiliate doit alors etre modi- 
fee pour se conformer a celle ci-dessous. 



Convention Pref ixer les noms des classes 
autogenerees 

Seules les classes qui ont ete autogenerees par 
Doctrine doivent etre prefixees avec le mot 
PI ugi n. II est strictement inutile de prefixer les 
classes ecrites manuellement. 
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Declaration de la classe abstraite PluginJobeetAffiliate dans le fichier plugins/ 
sfJobeetPlugin/lib/model/doctrine/PluginJobeetAffiliate.class.php 

abstract class PluginJobeetAffiliate extends 
j BaseJobeet Affiliate 

{ 

public function preValidate(Sevent) 
{ 

Sobject = $event->getInvoker() ; 

if (!$object->getToken()) 
{ 

$object->setToken(shal($object->getEmail () . rand (11111, 99999))) ; 

} 

} 

// ... 

} 

Le processus est a present exactement le meme pour la classe 
JobeetAf f i 1 i ateTabl e. 

$ mv pi ugins/sf JobeetPlugin/lib/model /doctrine/ 

JobeetAf fi 1 i ateTabl e . cl ass . php pi ugi ns/sf JobeetPl ugi n/1 i b/ 

model /doct ri ne/Pl ugi n JobeetAf f i 1 i ateTabl e . cl ass . php 

La classe concrete devient maintenant abstraite et se nomme 
PI ugi n JobeetAf fi 1 i ateTabl e. 

abstract class PI ugi nJobeetAffi "I i ateTabl e extends 
Doctrine Table 

{ 

// ... 

} 

Finalement, cette meme operation doit etre repetee et etendue a toutes 
les classes du modele, de formulaires et de filtres. II suffit tout d'abord de 
renommer le nom du fichier en prenant en compte le prefixe PI ugi n, et 
enfin de mettre a jour la definition de la classe afin de la rendre abstraite. 

Reconstruire le modele de donnees 

Une fois que toutes les classes autogenerees ont bien ete deplacees, 
renommees et rendues abstraites, le modele de donnees de Jobeet peut 
alors a son tour etre entierement reconstruit, afin de recreer les classes 
concretes qui n existent plus. 

Cependant, avant d'executer les taches automatiques de reconstruction 
des classes du modele, de formulaires et de filtres, toutes les classes de 
base de ces dernieres doivent etre supprimees du plug-in. Pour ce faire, il 
suffit simplement d'effacer le repertoire base/ qui se trouve dans chaque 



dossier plugins/sf JobeetPl ugi n/1 ib/*/doctri ne oil l'etoile remplace les 
valeurs model, form et filter. 

$ rm -rf pi ugi ns/sf JobeetPl ugi n/1 i b/form/doctri ne/base 
$ rm -rf plugins/sfJobeetPlugin/lib/filter/doctrine/base 
$ rm -rf plugins/sf JobeetPl ugi n/1 ib/model /doctrine/base 

Ce nest qua partir de cet instant que toutes les classes du modele peu- 
vent etre regenerees au niveau du projet en lancant successivement les 
commandes doctrine: build- - oil l'etoile prend pourvaleur model, forms 
et filters. 

$ php symfony doctri ne : bui 1 d-model s 
$ php symfony doctri ne : bui 1 d-forms 
$ php symfony doctrine:build-filters 

Le resultat de 1' execution de ces trois commandes conduit a la creation 
de nouveaux repertoires au niveau du projet. En effet, le repertoire 1 i b/ 
model /doctrine accueille desormais le dossier sf JobeetPl ugi n qui con- 
tient lui-meme les classes concretes et les classes de base autogenerees. 
Celles-ci possedent maintenant la structure suivante. 

• La classe JobeetJob herite des proprietes et methodes de la classe 
parente PluginJobeetJob, et se situe dans le fichier lib/model/ 
doctrine/sf JobeetPlugin/JobeetJob. class, php. JobeetJob est la 
classe la plus specifique et de plus haut niveau, c'est pour cette raison 
quelle peut accueillir les fonctionnalites specifiques du projet qui 
redefinissent les methodes predefinies du plug-in. 

• La classe PI ugi n JobeetJob herite des proprietes et methodes de la 
classe parente BaseJobeetJob, et se situe dans le fichier plugins/ 
sf JobeetPl ugi n/1 i b/model /doctri ne/Pl ugi n JobeetJob . cl ass . php. 
Cette classe contient l'ensemble des methodes propres au fonction- 
nement du plug-in en redefinissant les methodes autogenerees par 
Doctrine. 

• La classe BaseJobeetJob herite des proprietes et methodes de la 
classe parente sfDoctri neRecord , et se situe dans le fichier lib/ 
model /doctri ne/sf JobeetPl ugi n/base/Base JobeetJob . cl ass . php. 
C'est la classe de base generee a partir du schema YAJV1L de descrip- 
tion de la base de donnees a chaque fois que la tache doctrine: build- 
model est executee. 

• La classe JobeetJobTable herite des proprietes et methodes de la 
classe parente PI ugi n JobeetJobTable, et se situe dans le fichier lib/ 
model /doctri ne/sf JobeetPl ugi n/Jobeet JobTabl e . cl ass . php. 
JobeetJobTable suit exactement le meme principe que la classe 
JobeetJob a ceci pres que ce sera une instance Doctri ne_Table qui 
sera retournee a l'appel de Doctrine: :getTable(' JobeetJob' ). 



A RETENIR Mettre a jour les classes de 
formulaires d'un plug-in 

Lorsque les classes de formulaires sont deplacees 
vers le plug-in, il ne faut pas oublier de changer le 
nom de la methode configureO en 
setupO, puis d'appeler a I'interieur de celle-ci 
la methode setup () de la classe parente comme 
le montre le code ci-apres. 
abstract class 

PluginJobeetAffiliateForm extends 

BaseJobeetAffiliateForm 

{ 

public function setupO 
{ 

parent: : setupO ; 

} 



// 



} 



A RETENIR Localisation de la classe de base 
des filtres en Symfony 1.2.0 et 1.2.1 

Dans les versions 1.2.0 et 1.2.1 de Symfony, la 
classe de base des formulaires de filtres se trouve 
dans le repertoire plugins/ 
sf JobeetPl ugi n/1 i b/fi 1 ter/base/. 
Neanmoins, a I'heure oil nous ecrivons ces lignes, 
la version 1.2.5 de Symfony est deja sortie, c'est 
pourquoi il ne devrait plus y avoir de raison d'uti- 
liser des versions anterieures a celle-ci. 



A RETENIR Risques d'effets indesirables 
avec un accelerateur PHP 

Si un accelerateur PHP tel que APC est installe sur 
le serveur, il se pourrait que des comportements 
etranges se produisent apres toutes ces modifica- 
tions. Poury remedier, il suffit simplement de rede- 
marrer le serveur web Apache. 



• La classe PI ugi n Jobeet JobTabl e herite des proprieties et methodes de 
la classe parente Doctri ne_Table, et se situe dans le fichier lib/ 
model /doctri ne/sf JobeetPl ugi n/Pl ugi n Jobeet Job . cl ass . php. Cette 
classe contient l'ensemble des methodes propres au fonctionnement 
du plug-in et l'appel a Doctrine: : getTabl e( ' Jobeet Job ' ) retournera 
une instance de la classe Doctri ne_Table. 

Avec la structure de fichiers ainsi etablie, il devient possible de person- 
naliser les modeles d'un plug-in en editant la classe de haut niveau 
JobeetJob. De la meme maniere, le schema de la base de donnees peut 
lui aussi etre personnalise en ajoutant de nouvelles colonnes et relations, 
et en redefinissant les methodes setTableDefinitionO et setUpO. 

Supprimer les classes de base des formulaires Doctrine 

Maintenant, il faut s'assurer que le plug-in ne contient plus les classes de 
base des formulaires Doctrine, etant donne que celles-ci sont globales au 
projet et seront, quoi qu'il en soit, regenerees a 1' execution des taches 
automatiques doctrine:build-forms et doctrine:filters. Si les deux 
classes BaseFormDoctrine et BaseFormFilterDoctrine sont presentes 
dans le plug-in alors elles peuvent etre supprimees en toute securite. 

$ rm pi ugi ns/sf JobeetPl ugi n/1 i b/form/doctri ne/ 
BaseFormDoctri ne . cl ass . php 

$ rm plugins/sfJobeetPlugin/lib/filter/doctrine/ 
BaseFormFilterDoctrine. class. php 

Deplacer la classe Jobeet vers le plug-in 

Pour en finir avec le premier point des sept etapes successives a aborder, 
seule la classe Jobeet doit encore etre ajoutee dans le plug-in ; il suffit 
alors de la deplacer depuis le repertoire lib/ du projet jusque dans le 
dossier pi ugi ns/sf JobeetPl ugi n/1 i b/. 

| $ mv lib/Jobeet. class. php pi ugi ns/sf JobeetPl ugi n/1 i b/ 

Ceci etant fait, le cache de Symfony doit etre vide afin de prendre en 
compte l'ensemble de toutes les modifications apportees ainsi que les 
nouvelles classes du plug-in. Par la meme occasion, il s'avere pertinent 
de lancer toute la suite de tests unitaires et fonctionnels pour s'assurer 
que le processus de migration des classes du modele ha pas endommage 
l'application ou provoque de regression fonctionnelles. 



$ php symfony cc 
$ php symfony test 



:all 
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Migrer les contrdleurs et les vues 



Cette section aborde la seconde etape du processus de migration d'une 
application en plug- in. II y est question du deplacement des modules dans 
le repertoire du plug-in. La encore, il s'agit d'une etape decisive et 
perilleuse dans la mesure ou de nombreux changements devront etre 
operes au niveau du code et des templates. Neanmoins, les tests unitaires 
et fonctionnels accompagnent le developpeur dans ce processus de transi- 
tion afin de l'aider a deceler les parties du code qui provoquent des erreurs. 

Deplacer les modules vers le plug-in 

La premiere etape de cette nouvelle section consiste tout d'abord a creer 
un repertoire modules/ dans le plug-in afin d'y deplacer un a un tous les 
modules de l'application frontend de Jobeet. Cependant un probleme se 
pose : les noms des modules de Jobeet sont bien trop generiques pour 
pouvoir etre embarques de cette maniere dans un plug-in, lis risque- 
raient « d'entrer en collision » avec des modules du meme nom dans un 
projet different. Une bonne pratique est de renommer un a un les 
modules du plug-in sfDobeetPlugin en prenant le soin de tous les pre- 
fixer avec sf Jobeet. 

$ mkdi r plugins/sfDobeetPlugin/modules/ 

$ mv apps/f rontend/modules/affiliate pi ugi ns/sf DobeetPl ugi n/ 
modul es/sf JobeetAf f i 1 i ate 

$ mv apps/f rontend/modul es/api pi ugi ns/sf JobeetPl ugi n/modules/ 
sf JobeetApi 

$ mv apps/f rontend/modul es/category plugins/sf JobeetPl ugi n/ 
modul es/sf JobeetCategory 

$ mv apps/f rontend/modul es/job plugins/sfJobeetPlugin/modules/ 
sfDobeetJob 

$ mv apps/f rontend/modul es/language pi ugi ns/sf JobeetPl ugi n/ 
modul es/sf JobeetLanguage 

Renommer les noms des classes d'actions et de composants 

La modification des noms des modules de Jobeet a un impact immediat. 
Tous les noms des classes d'actions (fichiers actions.class.php) et de 
composants (fichiers components. cl ass. php) doivent etre modifies car 
Symfony repose principalement sur des conventions de nommage a res- 
pecter pour que l'ensemble reste coherent et fonctionnel. Ainsi, par 
exemple, le nom de la classe d'actions du module sf JobeetAffiliate 
devient sf JobeetAffiliateActions. Le tableau ci-dessous resume les 
changements a realiser pour chaque module. 



Tableau 19-1 Liste des modifications a apporter aux classes d'actions et de composants des modules du plug-in 



Module 


Nom de la classe d'actions 


Nom de la classe de composants 


sf JobeetAf f i 1 i ate 


sf JobeetAf f i 1 i ateActi ons 


sf JobeetAf fi 1 i ateComponents 


sf JobeetApi 


sf JobeetApi Actions 




sf JobeetCategory 


sf JobeetCategoryActions 




sf JobeetJob 


sf JobeetJobActions 




sf JobeetLanguage 


sf JobeetLanguageActions 





Mettre a jour les actions et les templates 

Bien evidemment, il existe encore des references aux anciens noms des 
modules a la fois dans les templates et dans le corps des methodes des 
actions. II est done necessaire de proceder a une mise a jour des noms des 
modules dans les helpers inc"lude_partia"l 0 et include_component() 
des templates suivants : 

• sf JobeetAf fi "I i ate/tempi ates/_form.php (changer affiliate en 
sf JobeetAf fi 1 i ate) 

• sf JobeetCategory/templ ates/showSuccess . atom . php 

• sf JobeetCategory/templ ates/showSuccess . php 

• sfjobeet Job/tempi ates/i ndexSuccess . atom . php 

• sfjobeet Job/tempi ates/i ndexSuccess . php 

• sfjobeet Job/tempi ates/searchSuccess . php 

• sfjobeet Job/tempi ates/showSuccess . php 

• apps/f rontend/templ ates/1 ayout . php 

De la meme maniere, les actions search et delete du module 
sf JobeetJob doivent etre editees afin de remplacer toutes les references 
aux anciens modules dans les methodes forwardO, redirectO ou 
renderPartial (). 

Mise a jour des actions search et delete du module sfJobeeUob dans le fichier 
plugins/sfJobeetPlugin/modules/sfJobeeUob/actions/actions.class.php 

class sf JobeetJobActions extends sfActions 
{ 

public function executeSearch(sfWebRequest $request) 
{ 

if (!$query = $request->getParameter('query')) 
{ 

return $thi s->forward('sf JobeetJob ' , 'index'); 

} 

$this->jobs = Doctrine: :getTable(' JobeetJob') - 
>getForl_uceneQuery($query) ; 
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cn 

Q. 

if ($request->isXm"IHttpRequest()) ^ 

{ 2 
if ('*' == $query || ! $thi s->jobs) 

{ 

return $thi s->renderText( ' No results.'); 

} 

el se 

{ 

return $this->renderPartia1 ( ' sf JobeetJob/1 ist ' , 

arrayC jobs' => $this->jobs)) ; 

} 

} 



public function executeDelete(sfWebRequest Srequest) 
{ 

$request->checkCSRFProtection() ; 

$jobeet_job = $thi s->getRoute()->getObject() ; 
$jobeet_job->delete() ; 

$thi s->redi rect ( ' sf JobeetJob/i ndex ' ) ; 

} 

// ... 



Mettre a jour le fichier de configuration du routage 

La modification des noms des modules du plug-in influe necessairement 
sur le fichier de configuration routing. yml qui contient lui aussi des 
references aux anciens noms des modules. Par consequent, l'ensemble 
des routes declarees dans ce fichier doivent etre editees. 

Contenu du fichier apps/frontend/config/routing.yml 

af f i 1 i ate : 

cl ass : sf Doct ri neRouteCol 1 ecti on 
options : 

model : JobeetAf f i 1 i ate 

actions: [new, create] 

object_actions : { wait: GET } 
pref i x_path : / : sf„cul tu re/af f i 1 i ate 
module: sfJobeetAff il iate 

requi rements : 

sf_culture: (?:fr|en) 

api_jobs: 

url : /api /: token/ jobs. :sf_format 

class: sfDoctri neRoute 

param: { module: sf JobeetApi , action: list } 

options: { model: JobeetJob, type: list, method: getForToken } 
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requi rements : 

sf_format: (?: xml | j son | yarn! ) 



E 



/ : sf_cul tu re/category/ : si ug . : sf_f ormat 
sfDoctri neRoute 

{ module: sf JobeetCategory , action: show, sf format 
{ model: JobeetCategory , type: object, method: 



category: 

url : 

class: 

param: 
html } 

options 
doSel ectForSl ug } 

requi rements : 

sf_format : (? : html | atom) 
sf^culture: (?:fr|en) 

job_search: 

url: /:sf_cultu re/search 

param: { module: sf Jobeet Job, action: search } 
requi rements : 

sf_culture: (?:fr|en) 



sfDoctri neRouteCol 1 ecti on 



job: 
class: 
options : 
model : 
col umn : 

object_actions : 
prefix_path : 
module: 
requi rements: 
token : \w+ 

sf_culture: (?:fr|en) 



JobeetJob 
token 

{ publish: PUT, extend: PUT } 
/ :sf_culture/job 
sf JobeetJob 



job_show_user : 

url : / :sf_cultu re/job/ :company_slug/:location_slug/: id/ 
:position_slug 
class: sfDoctri neRoute 
options : 

model : JobeetJob 

type: object 

method_for_query : retrieveActi veJob 
param: { module: sf JobeetJob, action: show } 
requi rements: 

id: \d+ 

sf_method: GET 

sf_culture: (?:fr|en) 



change_l anguage : 

url : /change_l anguage 

param: { module: sf Jobeet Language, action: changeLanguage } 

1 ocal i zed_homepage : 
url: /:sf_culture/ 

param: { module: sf Jobeet Job, action: index } 
requi rements : 

sf_culture: (?:fr|en) 
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homepage : 
url : / 

param: { module: sf JobeetJob, action: index } 

Activer les modules de ('application frontend 

La modification du fichier de configuration routing. yml conduit a de 
nouvelles erreurs. En effet, si Ton tente d'acceder a n'importe quelle page 
accessible depuis l'une de ces routes en environnement de developpe- 
ment, une exception est automatiquement levee par Symfony indiquant 
que le module en question nest pas active. 

Les plug-ins sont partages par toutes les applications du projet, ce qui 
signifie aussi que tous les modules sont potentiellement exploitables 
quelle que soit l'application. Imaginez ce que cela implique en termes de 
securite si un utilisateur parvenait a atteindre le module sfCuardUser 
depuis l'application frontend en decouvrant son URL. Cet exemple 
montre egalement la raison pour laquelle il est de bonne pratique de sup- 
primer manuellement les routes par defaut de Symfony du fichier de 
configuration routi ng . yml . 

Afin d'eviter ces potentielles failles de securite, le framework Symfony 
desactive par defaut tous les modules pour toutes les applications du 
projet, et c'est en fin de compte au developpeur lui-meme de specifier 
explicitement dans le fichier de configuration settings. yml de l'applica- 
tion, quels sont les modules qu'il souhaite activer ou pas. Cette operation 
se realise tres simplement en editant la directive de configuration 
enabled_modules de la section .settings du fichier de configuration 
comme le montre le code ci-dessous. 

Activation des modules du plug-in sfJobeetPlugin pour l'application frontend dans le 
fichier apps/frontend/config/settings.yml 

all : 

. setti ngs : 
enabled_modules: 

- default 

- sfDobeetAf filiate 

- sfDobeetApi 

- sfDobeetCategory 

- sfJobeetJob 

- sfDobeet Language 

La derniere etape du processus de migration des modules de Jobeet vers 
le plug-in sfJobeetPlugin consiste a corriger les tests fonctionnels qui 
controlent la valeur des modules dans l'objet requete, avant d'executer 
enfin toute la suite des tests en vue de s' assurer que tout est bien retabli. 



$ php symfony test: all 



Important Activer des plug-ins dans un projet Symfony 

Pour qu'un plug-in soit disponible dans un projet, il doit obligatoirement etre active dans la 
classe de configuration ProjectConf iguration qui se trouve dans le fichier conf i g/ 
ProjectConfiguration . class, php. Dans le cas present, cette etape n'est pas 
necessaire, puisque par defaut Symfony agit d'apres une strategie de « liste noire » {black list) 
qui consiste a activer tous les plug-ins a I'exception de ceux qui sont explicitement mentionnes. 

public function setupO 

{ 

$thi s->enabl eAl 1 PI ugi nsExcept(array( ' sf Doctri nePl ugi n ' , 

'sfCompatlOPlugin')) ; 

} 

Cette approche sert a maintenir une compatibilite retrograde avec d'anciennes versions de 
Symfony. Neanmoins, il est conseille de recourir a une approche par « liste blanche » {white 
list) qui consiste a tout desactiver par defaut, puis d'activer les plug-ins au cas par cas comme 
le prevoit la methode enabl ePl ugi ns(). 

public function setupO 

{ 



$thi s->enabl ePl ugi ns (array ( ' sf Doctri nePl ugi n ' , 
'sfDoctrineCuardPlugin' , 'sfFormExtraPlugin' , 
'sfJobeetPlugin')) ; 




Toutes les etapes critiques du processus de migration de Implication 
vers un plug-in sont desormais terminees. Les cinq etapes restantes ne 
sont que formalites, etant donne qu'il ne s'agit principalement que de 
copier des fichiers existants dans le repertoire du plug-in. 

Migrer les taches automatiques de Jobeet 

La migration des taches automatiques de Jobeet ne pose aucune diffi- 
culte puisqu'il s'agit tout simplement de copier le repertoire lib/task et 
ce qu'il contient dans le dossier plugins/sfJobeetPlugin/lib/. Une 
seule ligne de commande permet d'y parvenir. 

| $ mv lib/task pi ugi ns/sfJobeetPl ugi n/1 i b/ 

Migrer les fichiers d'internationalisation de 
■'application 

De la meme maniere qu'une application, un plug-in est capable 
d'embarquer des catalogues de traduction au format XLIFF. La tache 
consiste une fois de plus a deplacer le repertoire apps/f rontend/il8n et 
tout ce qu'il contient vers la racine du plug-in. 



$ mv apps/f rontend/i 18n pi ugi ns/sf JobeetPl ugi n/ 

Migrer le fichier de configuration du routage 

La declaration des regies de routage peut egalement s'effectuer au niveau 
du plug-in ; c'est pourquoi dans le cadre de Jobeet, il convient de 
deplacer le fichier de configuration routing. yml dans le repertoire 
config/ du plug-in. 

j $ mv apps/f rontend/config/routing. yml pi ugi ns/sf DobeetPl ugi n/config/ 

Migrer les ressources Web 

Bien que ce ne soit pas toujours tres intuitif, un plug-in a aussi la possibi- 
lite de contenir un jeu de ressources web comme des images, des feuilles de 
style en cascade ou bien encore des fichiers JavaScript. Dans la mesure ou 
le plug-in de Jobeet n'a pas vocation a etre distribue, il nest pas necessaire 
d'inclure de ressources web. Toutefois, il faut savoir que c'est possible en 
creant simplement un repertoire web/ a la racine du plug-in. 

Les ressources d'un plug-in doivent etre accessibles dans le repertoire 
web/ du projet afin d'etre atteignables depuis un navigateur web. Le fra- 
mework Symfony fournit nativement la tache automatique 
plugin:publish-assets qui se charge de creer les liens symboliques ade- 
quats sur les systemes Unix, ou de copier les fichiers lorsqu'il s'agit de 
plates-formes Windows. 

| $ php symfony pi ugi n : publ i sh-assets 

Migrer les fichiers relatifs a I'utilisateur 

Cette derniere etape est un peu plus complexe et cruciale que les autres 
puisqu'il s'agit de deplacer le code du modele myUser dans une autre 
classe de modele dediee au plug-in. La section suivante explique tout 
d'abord quels sont les problemes que Ton rencontre lorsque Ton deplace 
du code relatif a I'utilisateur, puis en profite pour apporter une solution 
alternative afin d'y remedier. 

Configuration du plug-in 

Bien evidemment, il n'est nullement envisageable de copier le fichier de 
la classe myUser directement dans le plug-in etant donne que celle-ci 
depend de l'application, et pas particulierement de Jobeet. Une autre 
solution eventuelle consisterait a creer une classe JobeetUser dans le 



A RETENIR Notion de classe 
appelable en PHP (callable) 

Une variable PHP appelable (callable) est une 
variable qui peut etre utilisee par la fonction 
ca"ll_user_func() et qui renvoie true 
lorsqu'elle est testee comme parametre de la fonc- 
tion is_ca11ab1e(). 

La methode i s_cal 1 abl e() accepte en pre- 
mier argument soit une chame de caracteres qui 
contient le nom d'une fonction utilisateur appelable, 
soit un tableau simple avec deux entrees. Ce 
tableau peut contenir soit un objet et le nom d'une 
de ses methodes publiques, soit le nom d'une classe 
et une methode statique publique de celle-ci. 

► http://fr.php.net/manual/fr/ 
function.call-user-func.php 

► http://fr.php.net/manual/fr/ 
function. is-callable.php 



plug-in, dans laquelle figurerait tout le code relatif a l'historique des 
offres de l'utilisateur, et dont la classe myllser devrait heriter. 

C'est en effet une meilleure approche puisqu'elle isole correctement le 
code propre au plug-in sf JobeetPlugin de celui qui est propre a l'appli- 
cation. Neanmoins, cette solution a ses propres limites puisqu'elle 
empeche l'objet myUser de 1' application de recevoir du code metier de la 
part de plusieurs plug-ins en meme temps. C'est exactement le cas ici 
dans la mesure ou l'objet myUser est cense accueillir des methodes en 
provenance des plug-ins sfDoctrineCuardPlugin et sf JobeetPl ugi n, et 
ou malheureusement, PHP ne permet pas l'heritage de classes multiples. 
II faut done resoudre le probleme differemment, grace notamment au 
nouveau gestionnaire d'evenements de Symfony. 

Au cours de leur cycle de vie, les objets du noyau de Symfony notifient 
des evenements que Ton peut ecouter. Dans le cas de Jobeet, il convient 
d'ecouter l'evenement user.method_not_found, qui se produit lorsqu'une 
methode non definie est appelee sur l'objet sfUser. 

Lorsque Symfony est initialise, tous les plug-ins le sont aussi a condition 
qu'ils disposent d'une classe de configuration similaire a celle ci-dessous. 

Contenu de la classe de configuration du plug-in sfJobeetPlugin dans le fichier 
plugins/sfJobeetPlugin/config/sfJobeetPluginConfiguration.class.php 

class sfDobeetPluginConfiguration extends sfPluginConfiguration 

{ 

public function initialize() 
{ 

$this->di spatcher->connect ( ' user . method not found ' , 
array('JobeetUser ' , 'methodNotFound')) ; 

} 

} 

Les notifications d'evenements sont entierement gerees par l'objet 
sfEventDispatcher. Enregistrer un ecouteur d'evenement est simple 
puisqu'il s'agit d'appeler la methode connect () de cet objet afin de con- 
necter le nom d'un evenement a une classe PHP appelable {PHP callable). 

Developpement de la classe JobeetUser 

Grace au code mis en place juste avant, l'objet myUser sera capable 
d'appeler la methode statique methodNotFoundO de la classe JobeetUser 
a chaque fois quelle sera dans l'impossibilite de trouver une methode. II 
appartient ensuite a la methode methodNotFoundO de traiter la fonction 
manquante ou non. 
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Pour y parvenir, toutes les methodes de la classe myUser doivent etre sup- 
primees, avant de creer la nouvelle classe JobeetUser suivante dans le 
repertoire 1 i b/ du plug-in. 

Contenu de la classe myUser du fichier apps/frontend/lib/myUser.class.php 

class myUser extends sfBasicSecurityUser 

{ 

} 

Contenu de la classe JobeetUser du fichier plugins/sfJobeetPlugin/lib/ 
JobeetUser.class.php 

class JobeetUser 
{ 

static public function methodNotFound(sfEvent $event) 
{ 

if (method exists ('JobeetUser' , $event['method'])) 
{ 

$event->setReturnValue(call user func array ( 
ar ray (' JobeetUser ' , $event[' method']) , 

array merge(array($event->getSubject()) , $event[' arguments']) 

)); 

return true; 

} 

} 

static public function isFirstRequest(sfUser $user, Sboolean = null) 

{ 

if (is_null (Sboolean)) 
{ 

return $user->getAttri bute( ' f i rst_request ' , true); 

} 

el se 

{ 

$user->setAttribute('fi rst_request' , Sboolean) ; 

} 

} 

static public function addJobToHi story (sf User $user, JobeetJob $job) 

{ 

$ids = $user->getAttribute(' job_hi story ' , arrayO); 

if (Hn_array($job->getId() , $ids)) 
{ 

array_unshift($ids, $job->getId()) ; 

$user->setAttribute('job_history' , array_sl i ce($i ds , 0, 3)); 

} 

} 



static public function get JobHistory(sf User $user) 

{ 

$ids = $user->getAttribute(' job_history' , arrayO); 

if (!empty($ids)) 
{ 

return Doctrine: : getTabl e( ' JobeetDob ' ) 

->createQuery ( ' a ' ) 

->whereln('a.id' , $ids) 

->execute() ; 
} else { 

return arrayO ; 

} 

} 

static public function resetJobHistory(sfUser $user) 

{ 

$user->getAttri buteHol der() -> remove ( ' job_hi story' ) ; 

} 

} 

Lorsque le dispatcheur d'evenements appelle la methode statique 
methodNotFoundO, il lui passe un objet sfEvent en parametre. Cet objet 
dispose d'une methode getSubjectO qui renvoie le notificateur de l'eve- 
nement qui, dans le cas present, correspond a l'objet courant myUser. 

La methode methodNotFoundO teste si la methode que Ton essaie 
d'appeler sur l'objet sfUser existe dans la classe JobeetUser ou pas. Si 
celle-ci est presente, alors elle est appelee dynamiquement et sa valeur 
est immediatement retournee au notificateur par le biais de la methode 
setReturnedVal ue() de l'objet sfEvent. Dans le cas contraire, Symfony 
essaiera le tout prochain ecouteur enregistre ou lancera une exception. 

Avant de tester ces dernieres modifications appliquees au projet, il ne 
faut pas oublier de vider le cache de Symfony puisque de nouvelles 
classes ont ete ajoutees. 

$ php symfony cc 



Comparaison des structures des projets et des plug-ins 

En resume, l'approche par plug-in permet a la fois de rendre le code plus 
modulaire et reutilisable a travers les projets, mais permet aussi d'orga- 
niser le code du projet d'une maniere plus formelle, puisque chaque 
fonctionnalite essentielle se trouve isolee a sa place dans le bon plug-in. 
Le schema ci-dessous illustre les changements necessaires pour passer 
d'une architecture d'un projet a celle d'un plug-in. 



Structure par defaut 



Architecture d'un plugin 



apps/ 
frontend/ 
config/ 
routing. yml 

il8n/- 

modules/ 
job/ 
config/ 

schema. yml 
lib/ 
filter/ 
form/ 
model/ 
task/ 
web/ 




plugins/ 
sf JobeetPlugin/ 
config/ 
— ^ routing. yml 
schema. yml 
il8n/ 
lib/ 
filter/ 
form/ 
model/ 
task/ 
modules/ 
sf DobeetJob/ 
^ web/ 



Figure 19-1 

Comparaison des architectures des projets 
et des plug-ins 



Utiliser les plug-ins de Symfony 



Naviguer dans l'interface dediee aux plug-ins 



Search 

Find the plugins available for your version(s) of symfony and the ORM(s) you use. 
Filter them by category or plugin/developer name. 



symfony Version 

^sf 1.0 
gsf 1.1 
tfsf 1.2 




Other filters 

Category 
Plugin or Developer name 

Only stable plugins? D 



( search 1 



By Category 

Applications (761 Backend (681 Behavior (271 Development (201 Doio (31 Email (81 Ext (13) Forms (411 Internationalization (121 
JavaScript (43) iOuerv (10) Media (30) Model (36) Performance (19) Prototype (18) Search (7) Security (37) Spam (9) 
Template (30) WebServices (28) Widget (27) YUI (5) all plugins » 



Newest □ 

• 27/03 14:26 - sfVizzupPluain 

• 24/03 18:27 - eeMooToolsAutocompleterPluain 

• 24/03 16:04 - sfEleAdminEmailPluain 

• 24/03 10:48 - pmDewplaverPluain 

• 22/03 09:01 - sfSympalBloa Plugin 

• 22/03 06:03 - sfSCMIgnoresTaskPlugin 

• 22/03 00:32 - sfFeedBurnerPluqin 

• 20/03 01:12 - sflmaginablePlugin 

• 19/03 18:49 - sfEleAdminBannerPlugin 

• 16/03 21:39 - sfDoctrineAtcAsSortablePluain 



Recently Updated 0 



cbenz 



27/03 18:42 - eeMooToolsAutocompleterPlugin - 1.0.1 ■ 
27/03 18:13 - eeVlaDatePickerPlugin - 0.1.6 - cbenz 
27/03 16:21 - sfVizzupPlugin - 1.0.0 • tali 
27/03 15:24 - sfAtosPavmentPlugin - 0.5.0 - lombardot 
26/03 21:40 - SfSCMIgnoresTaskPlugin - 1.0.2 - daum 
26/03 15:14 - sfEleAdminEmailPluoin - 0.8.0 - Thvaao Clemente 
26/03 12:11 - sfSphinxPlugin - 0.0.7 - garak 
24/03 14:50 - pmDewplaverPlugin - 1.0.1 - pmacadden 
24/03 03:14 - sfSCMIqnpresTaskPluoin - 1.0.1 - daum 
23/03 00:04 - sfFeedBurnerPlugin - 1.0.1 - laurentb 



Figure 19-2 Page d'accueil de l'interface des plug-ins du site officiel de Symfony 
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Lorsqu'il s'agit de demarrer l'implementation d'une nouvelle fonction- 
nalite, ou quand un probleme recurrent des applications web doit etre 
resolu, il y a de fortes chances que quelqu'un ait deja rencontre et solu- 
tionne ce probleme. Dans ce cas, le developpeur aura probablement pris 
le temps de packager sa solution dans un plug-in Symfony. 

Le site officiel du projet Symfony dispose d'une section entierement 
dediee aux plug-ins concus par l'equipe de developpement et la commu- 
naute, a travers laquelle il est possible de rechercher differentes sortes de 
plug-ins. Ce depot est aujourd'hui riche de plus de 500 plug-ins repartis 
a travers differentes rubriques comme la securite, les formulaires, les e- 
mails, l'internationalisation, les services web, le JavaScript... 

Les differentes manieres d'installer des plug-ins 

Comme un plug-in est un paquet entierement autonome compris dans 
un seul et meme repertoire, il existe plusieurs moyens de l'installer. 
Jusqu'a present, c'est la methode la plus courante qui a ete employee, 
c'est-a-dire l'installation grace a la tache automatique pi ugi n : i nstal 1 . 

• Utiliser la tache automatique pi ugi n : i nstal 1 . Cette derniere ne fonc- 
tionne qua condition que l'auteur du plug-in ait convenablement cree 
le package du plug-in, puis depose celui-ci sur le site de Symfony. 

• Telecharger le package manuellement et decompresser son contenu 
dans le repertoire plugins/ du projet. Cette installation implique 
egalement que l'auteur a depose son package sur le site de Symfony. 

• Ajouter le plug-in externe a la propriete svn : external s du repertoire 
plugins/ du projet a condition que le plug-in soit heberge sur un 
depot Subversion. 

Les deux dernieres methodes sont simples et rapides a mettre en oeuvre 
mais moins flexibles, tandis que la premiere permet d'installer la toute 
derniere version disponible du plug-in, en fonction de la version du fra- 
mework utilisee. De plus, elle facilite la mise a jour d'un plug-in vers sa 
derniere version stable, et gere aussi aisement les dependances entre cer- 
tains plug-ins. 

Technique La propriete svn:externals de Subversion 

La propriete svn : external s de Subversion permet d'ajouter a la copie de travail locale, les 
fichiers d'une ou de plusieurs ressources externes versionnees et maintenues sur un depot Sub- 
version distant. En phase de developpement, I'utilisation de cette technique a I'avantage de ne 
pas avoir a gerer soi-meme les composants externes utiles a un projet (Swit Mailer par exemple), 
mais aussi de garder automatiquement la version de ces derniers a jour des dernieres modifica- 
tions. Lors du passage en production finale, la propriete svn : external s peut ainsi etre 
editee pour figer les versions des librairies externes a inclure, afin de ne pas risquer de recuperer 
des fichiers potentiellement instables de ces dernieres par le biais d'un svn update. 



Contribuer aux plug-ins de Symfony 

Packager son propre plug-in 
Construire le fichier README 

Pour creer le paquet d'un plug-in, il est necessaire d'ajouter quelques 
fichiers obligatoires dans la structure interne du plug-in. Le premier, et 
sans doute le plus important de tous, est le fichier README qui est situe a 
la racine du plugin, et qui explique comment installer le plug-in, ce qu'il 
fournit mais aussi ce qu'il n'inclut pas. 

Le fichier README doit egalement etre formate avec le format Markdown. 
Ce fichier sera utilise par le site de Symfony comme principale source de 
documentation. Une page disponible a l'adresse http://www.symfony- 
project.org/plugins/markdown_dingus permet de tester les fichiers README en 
convertissant le Markdown en code HTML. 

Ajouter le fichier LICENSE 

Un plug-in a egalement besoin de son propre fichier LICENSE dans lequel 
est mentionnee la licence qu'attribue l'auteur a son plug-in. Choisir une 
licence n'est pas une tache evidente, mais la section des plug-ins de Sym- 
fony liste uniquement ceux qui sont publies sous une licence similaire a 
celle du framework (MIT, BSD, LGPL et PHP). Le contenu du fichier 
LICENSE sera affiche dans l'onglet License de la page publique du plug-in. 

Ecrire le fichier package.xml 

La derniere etape du processus de creation d'un plug-in Symfony con- 
siste en l'ecriture du fichier package.xml a la racine du plug-in. Ce 
fichier decrit la composition du plug-in en suivant la syntaxe des paquets 
PEAR, disponible a l'adresse http://pear.php.net/manual/en/guide- 
developers.php. Le meilleur moyen d'apprendre a rediger ce fichier est 
sans aucun doute de s'appuyer sur le fichier d'un plug-in existant tel que 
le celebre sfGuardPlugin accessible a l'adresse http://svn.symfony- 
project.com/plugins/sfGuardPlugin/branches/1.2/package.xml. 

Structure generate du fichier package.xml 

Contenu du fichier plugins/sfJobeetPlugin/package.xml 

<?xml version="1.0" encodi ng="UTF-8"?> 
<package packagerversion="1.4.1" version="2.0" 
xml ns="http : //pear . php . net/dtd/package-2 . 0" 



Remarque laches automatiques de 
developpement de plug-ins 

Pour repondre a des besoins frequents de creation 
de plug-ins prives ou publics, il parait judicieux de 
tirer parti de quelques-unes des taches du plug-in 
sfTaskExtraPl ugi n. Ce dernier est deve- 
loppe et maintenu par I'equipe de developpement 
de Symfony, et inclut un certain nombre de taches 
qui facilitent la rationalisation du cycle de vie des 
plug-ins. 

generate: plugin 
plugin: package 
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xml ns : tasks="http ://pear . php . net/dtd/tasks-1.0" 
xml ns : xsi ="http : //www. w3 . org/2001/XMLSchema-i nstance" 
xsi : schemal_ocation=" http://pear.php. net/dtd/tasks-1.0 
http: //pear. php. net/dtd/tasks-l.O.xsd http://pear.php.net/ 
dtd/package-2 . 0 

http://pear.php.net/dtd/package-2 .O.xsd" 

> 

<name>sf DobeetPI ugi n</name> 

<channel>pl ugi ns . symfony-project . org</channe"l> 
<summary>A job board plugin.</summary> 
<description>A job board pi ugi n . </descri pti on> 
<lead> 

<name>Fabien POTENCIER</name> 
<user>fabpot</user> 

<emai 1 >f abi en . potenci e r@symf ony-pro j ect . com</emai 1 > 
<acti ve>yes</acti ve> 
</l ead> 

<date>2008-12-20</date> 
<version> 

<release>1.0.0</release> 

<api>1.0.0</api> 
</version> 
<stabi"lity> 

<rel ease>stab1 e</ rel ease> 

<api>stabl e</api> 
</stability> 

<1 i cense u ri ="http : //www. symfony-project . com/1 i cense"> 

MIT license 
</license> 
<notes /> 

<contents> 

<!-- CONTENT --> 
</contents> 

<dependencies> 

<!-- DEPENDENCIES --> 
</dependencies> 

<phpre1ease> 
</phprel ease> 

<change"log> 

<!-- CHANCELOG --> 
</change"log> 
</package> 

Le noeud contents du fichier package.xml 

La balise <contents> sert a decrire tous les fichiers et repertoires qui doi- 
vent figurer dans le plug-in. 

i <contents> 

<di r name="/"> 



<file role="data" name="README" /> 
<file role="data" name="LICENSE" /> 

<dir name="conf i g"> 

<fi1e role="data" name="confi g . php" /> 

<fi1e role="data" name="schema.yml " /> 
</di r> 

<!-- ... --> 
</di r> 
</contents> 

Le noeud dependencies du fichier package.xml 

Le noeud <dependencies> reference toutes les dependances necessaires 
au bon fonctionnement du plug-in comme PHP, Symfony, ou encore les 
plug-ins. Cette information est utilisee par la tache automatique 
pi ugi' n: task pour installer a la fois la meilleure version du plug-in pour 
l'environnement du projet, mais aussi pour installer toutes les depen- 
dances obligatoires supplementaires si elles existent. 

<dependencies> 
<requi red> 
<php> 

<min>5.0.0</min> 
</php> 

<pearinstaner> 

<min>1.4.1</min> 
</pearinstaller> 
<package> 

<name>symfony</name> 

<channel>pear . symfony-project.com</channel> 
<mi n>l. 2 . 0</mi n> 
<max>l . 3 . 0</max> 
<excl ude>l. 3 . 0</excl ude> 
</package> 
</ requi red> 
</dependencies> 

II est recommande de toujours declarer la dependance avec Symfony 
comme presente ici. Declarer une version minimale et maximale permet 
a la tache pi ugi n : i nstal 1 de savoir quelle version de Symfony est neces- 
saire etant donne que les versions de Symfony peuvent avoir des APIs 
legerement differentes. 

Declarer une dependance avec un autre plug-in est aussi possible comme 
le presente le code XML ci-dessous. 

<package> 

<name>sf FooPl ugi n</name> 

<channe1>plugins . symfony-project .org</channel> 



<min>1.0.0</min> 
<max>l . 2 . 0</max> 
<excl ude>l . 2 . 0</excl ude> 
</package> 

Le noeud changelog du fichier package.xml 

La balise <changelog> est optionnelle, mais donne de nombreuses infor- 
mations utiles a propos de ce qui a change entre les versions. Cette 
donnee est affichee dans l'onglet Changelog de la page publique du plug- 
in ainsi que dans le flux RSS dedie de ce celui-ci. 

<changelog> 
<release> 
<version> 

<rel ease>l . 0 . 0</rel ease> 

<api>1.0.0</api> 
</version> 
<stability> 

<rel ease>stabl e</rel ease> 

<api >stabl e</ api > 
</stability> 

<1 i cense uri="http ://www. symfony-project . com/1 i cense"> 

MIT license 
</l i cense> 

<date>2008-12-20</date> 
<1 i cense>MIT</l i cense> 
<notes> 

* fabien: First release of the plugin 
</notes> 
</rel ease> 
</changelog> 

Heberger un plug-in public dans le depot officiel de 
Symfony 

Heberger un plug-in utile sur le site officiel de Symfony afin de le par- 
tager avec la communaute Symfony est extremement simple. La pre- 
miere etape consiste a se creer un compte sur le site de Symfony, puis a 
creer un nouveau plug-in depuis l'interface web dediee. 

Le role d'administrateur du plug-in est automatiquement attribue a 
l'auteur de la source. Par consequent, un onglet admin est present dans 
l'interface. Cet onglet integre tous les outils et informations necessaires 
pour gerer les plug-ins deposes et telecharger les paquets sur le depot de 
Symfony. Une foire aux questions (FAQ) dediee aux plug-ins est egale- 
ment disponible afin d'apporter un lot d'informations utiles a tous les 
developpeurs de plug-ins. 



En resume 



Creer des plug-ins et les partager avec la communaute est l'une des 
meilleures facons de contribuer au projet Symfony. C'est si simple a 
mettre en place que le depot officiel des plug-ins de Symfony regorge de 
plug-ins utiles ou futiles, mais souvent pratiques. 

L'application Jobeet arrive doucement a son terme mais il reste encore 
deux points essentiels a aborder : la gestion du cache de Symfony et le 
deploiement du projet sur le serveur de production. Ces deux sujets seront 
respectivement traites dans les deux derniers chapitres de cet ouvrage. . . 
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La gestion du cache 



MOTS-CLES 



En environnement de production, une application web 

se doit d'etre fonctionnelle, comme l'etablissent 

ses specifications, mais aussi performante. Le temps 

de chargement des pages web est le principal indicateur 

de performance d'un site Internet et se doit d'etre le plus bas 

possible. 

De nombreuses strategies d'optimisation des pages existent, 
telle la mise en cache des pages HTML, integree nativement 
dans Symfony. 



► Templates, formula ires, partiels, 
composants 

► Environnement de production 

► Tests fonctionnels 



La question de la performance est plus ou moins commune a toutes les 
applications web modernes. Le premier critere d'evaluation de perfor- 
mance d'un site Internet est, bien entendu, le calcul du temps de charge- 
ment de ses pages. En fonction des resultats obtenus, il convient de 
proceder ou pas a des travaux d'optimisation en commencant par inte- 
grer au site un cache des pages. 

Le framework Symfony integre nativement plusieurs strategies de cache 
en fonction des types de fichier qu'il manipule. Par exemple, les fichiers 
de configuration YAML ou encore les catalogues de traduction XLIFF 
sont d'abord convertis en PHP puis sont ensuite mis en cache sur le sys- 
teme de fichier. De plus, le chapitre 12 a montre que les modules 
generes par le generateur d'administration sont eux aussi caches pour de 
meilleures performances. 

Ce vingtieme et avant dernier chapitre aborde un autre type de cache : le 
cache de pages HTML. Afin d'ameliorer les performances d'une appli- 
cation web, certaines pages du site peuvent etre mises en cache. 

Pourquoi optimiser le temps de chargement 
des pages ? 

La performance d'une application web constitue un point crucial dans la 
reussite de celle-ci. En effet, un site Internet se doit d'etre accessible en 
permanence afin de repondre aux besoins des utilisateurs. Or, la satisfac- 
tion des exigences des utilisateurs commence a partir du moment ou ces 
derniers se connectent a l'application et attendent que la page se charge 
completement. 

Le temps que met la page a s'afficher entierement est un indicateur fon- 
damental puisqu'il permet a l'utilisateur de determiner s'il souhaite pour- 
suivre ou non sa navigation. Des sites a fort trafic comme Google, 
Yahoo!, Dailymotion ou encore Amazon ont bien compris la necessite 
de consacrer du temps (et de l'argent) a l'optimisation des temps de 
chargement de leurs pages. Pour etayer ces propos il faut savoir qu'un 
site comme Amazon perd 1 % de ses ventes si le temps de chargement 
de ses pages web augmente de 100 ms. Le site Internet de Yahoo!, quant 
a lui, accuse en moyenne 5 a 9 % d'abandons lorsque ses pages web met- 
tent 400 ms de plus a s'afficher, tandis que Google avoue perdre en 
moyenne 20 % de frequentation par demi-seconde de chargement sup- 
plemental. Ce dernier chiffre explique entre autres l'extreme simplicite 
de l'interface du moteur de recherche Google et du nombre restreint de 
liens par page sur leurs pages de resultats 1 . 



Bien sur, pour en arriver a un tel point de performance, les equipes de 
developpement de ces sites Internet investissent beaucoup pour mettre 
en place des strategies d'optimisation a la fois cote serveur et cote client. 
Ces chiffres ont pour unique but de demontrer en quoi le temps de char- 
gement des pages web d'une application est determinant pour sa fre- 
quentation et ses objectifs commerciaux lorsqu'il s'agit d'un site de 
ventes en ligne par exemple. 

Le framework Symfony, qui est par ailleurs utilise par certains sites de 
Yahoo! et par Dailymotion, participe a l'elaboration de ce processus 
d'optimisation en fournissant un systeme de cache des pages HTML 
puissant et configurable. II rend possible un choix d'optimisation au cas 
par cas en permettant d'ajuster pour chaque page la maniere dont elle 
doit etre traitee par le cache. 

Creer un nouvel environnement pour tester 
le cache 

Comprendre la configuration par defaut du cache 

Par defaut, la fonctionnalite de cache des pages HTML de Symfony est 
activee uniquement pour l'environnement de production dans le fichier de 
configuration settings. yml de 1'appiication. En revanche, les environne- 
ments de developpement et de test n'activent pas le cache afin de pouvoir 
toujours visualiser immediatement le resultat des pages web tel qu'il sera 
livre par le serveur au client en environnement de production final. 

prod : 

.settings: 
cache: on 

dev: 

. setti ngs : 
cache: off 

test: 

. setti ngs : 
cache: off 



1. Chiffres recueillis lors d'une conference d'Eric Daspet au forum PHP 2008 a Paris. 



Ajouter un nouvel environnement cache au projet 



Securite Empecher I'execution des 
contrdleurs frontaux sensibles 

Le code du controleur frontal debute par un script 
qui s'assure que ce dernier est uniquement appele 
depuis une adresse IP locale. Cette mesure de 
securite sert a proteger les controleurs frontaux 
sensibles d'etre appeles sur le serveur de produc- 
tion. Ce sujet sera detaille plus en detail au cha- 
pitre suivant. 



Configuration generate de I'environnement cache 

L'objectif de ce chapitre est d'apprehender et de tester le systeme de 
cache des pages de Symfony avant de basculer le projet sur le serveur de 
production. Cette derniere etape constitue d'ailleurs l'objet du dernier 
chapitre. Deux solutions sont possibles pour tester le cache : activer le 
cache pour I'environnement de developpement (dev) ou creer un nouvel 
environnement. II ne faut pas oublier qu'un environnement se definit par 
son nom (une chaine de caracteres), un controleur frontal associe, et 
optionnellement un jeu de valeurs de configuration specifiques. 

Pour manipuler le systeme de cache des pages de Jobeet, un nouvel envi- 
ronnement cache sera cree et sera similaire a celui de production, a la 
difference que les logs et les informations de debogage seront disponi- 
bles. II s'agira done d'un environnement intermediate a la croisee des 
environnements dev et prod. 

Creer le controleur frontal du nouvel environnement 

La premiere etape de ce processus de creation d'un nouvel environne- 
ment pour le cache est de generer a la main un nouveau controleur 
frontal. Pour ce faire, il suffit de copier le fichier f rontend^dev.php, puis 
de le copier en le renommant f rontend_cache . php. 

Enfin, la valeur dev du second parametre de la methode statique 
getAppl i cati onConfigu rati on() de la classe ProjectConfiguration doit 
etre remplacee par cache. 

Contenu du fichier web/frontend_cache.php 

if ( ! i n_array(@$_SERVER[ ' REMOTE_ADDR' ] , array('127. 0.0.1' , 

'::1'))) 

{ 

die('You are not allowed to access this file. Check 
'.basenamef FILE ).' for more information.'); 

} 

requi re_once(di rname( FILE ) . '/. ./config/ 

, ProjectConfiguration. class. php') ; 

$configuration = 

Pro j ectConf i gu rati on : : getAppl i cati onConf i gu rati on ( ' f rontend ' , 
'cache' , true) ; 

sf Context : : createlnstance($configuration)->di spatch() ; 

Le 3 e parametre booleen de la methode getAppl i cati onConfigu rati on () 
permet d'activer les informations de debogage comme e'est deja le cas sur 
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l'environnement de developpement. Ce nouvel environnement cache est 
desormais testable en 1' appelant a partir d'un navigateur web par le biais 
de l'url http://jobeet.localhost/frontend_cache.php/. 

Configurer le nouvel environnement 

Pour l'instant, l'environnement cache herite de la configuration par 
defaut de Symfony. Pour lui definir une configuration particuliere, il 
suffit d'editer le fichier settings. yml de 1' application frontend en lui 
ajoutant les parametres de configuration specifiques pour l'environne- 
ment cache. 

Configuration de l'environnement cache dans le fichier apps/frontend/config/settings.yml 

cache : 

. setti ngs : 

error_reporting: <?php echo (E_ALL | E_STRICT) . "\n" ?> 

web_debug: on 

cache: on 

etag : off 

Ces parametres de configuration activent le niveau de traitement des 
erreurs le plus fort (error_reporting), la barre de debogage de Symfony 
(web_debug) et bien sur le cache des pages HTML via la directive de 
configuration cache. Comme la configuration par defaut met en cache 
tous ces parametres, il est necessaire de le nettoyer afin de pouvoir cons- 
tater les changements dans le navigateur. 

j $ php symfony cc 

Au prochain rafraichissement de la page dans le navigateur, la barre de 
debogage de Symfony devrait etre presente dans Tangle superieur droit de 
la fenetre, comme c'est deja le cas en environnement de developpement. 



Manipuler le cache de Implication 

Les sections suivantes entrent veritablement dans le vif du sujet car il 
s'agit de presenter les differentes strategies de configuration du cache de 
Symfony pour l'application Jobeet. En effet, le systeme de cache natif du 
framework ne s'arrete pas uniquement a la mise en cache de l'integralite 
des pages qu'il genere, mais laisse la possibilite de choisir quelles pages, 
quelles actions ou encore quels templates doivent etre mis en cache. 



Configuration globale du cache de I'application 



ASTUCE Configurer le cache differemment 

Une autre maniere de gerer la configuration du 
cache est egalement possible. II s'agit de faire 
I'inverse, c'est-a-dire d'activer le cache globalement 
puis de le desactiver ponctuellement pour les pages 
qui n'ont pas besoin d'etre mises en cache. Finale- 
ment, tout depend de ce qui represents le moins de 
travail pour I'application et pour le developpeur. 



ASTUCE Le fichier cache.yml 

Le fichier de configuration cache.yml possede 
les memes proprietes que tous les autres fichiers 
de configuration tels que view.yml. Cela 
signifie par exemple que le cache peut etre active 
pour toutes les actions d'un meme module en utili- 
sant la section speciale al 1 . 



Le mecanisme de cache des pages HTML peut etre configure a l'aide du 
fichier de configuration cache.yml qui se situe dans le repertoire config/ 
de I'application. A chaque fois qu'une nouvelle application est generee 
grace a la commande generate :app, Symfony construit ce fichier et 
attribue par defaut une configuration minimale du cache. 

default: 

enabled: off 

with_layout: false 

lifetime: 86400 

Par defaut, comme les pages peuvent toutes contenir des informations 
dynamiques, le cache est desactive (enabled: off) de maniere globale 
pour toute I'application. II est inutile de modifier ce parametre de confi- 
guration car le cache sera active ponctuellement page par page dans la 
suite de ce chapitre. Le parametre de configuration lifetime determine 
la duree de vie du cache en secondes sur le serveur. Ici, la valeur 
86 400 secondes correspond a une journee complete. 

Activer le cache ponctuellement page par page 

Activation du cache de la page d'accueil de Jobeet 

Comme la page d'accueil de Jobeet sera sans doute la plus visitee de tout 
le site Internet, il est particulierement pertinent de la mettre en cache 
afin d'eviter d'interroger la base de donnees a chaque fois que l'utilisa- 
teur y accede. En effet, il est inutile de reconstruire completement la 
page si celle-ci a deja ete generee une premiere fois quelques instants 
auparavant. Pour forcer la mise en cache de la page d'accueil de Jobeet, il 
suffit de creer un fichier cache.yml pourle module sfJobeetJob. 

Configuration du cache de la page d'accueil de Jobeet dans le fichier plugins/ 
sfJobeetJob/modules/sfJobeetJob/config/cache.yml 

index: 

enabled: on 
with_layout: true 

En rafraichissant le navigateur, on constate que Symfony a decore la 
page avec une boite bleue indiquant que le contenu a ete mis en cache 
sur le serveur. 
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Figure 20-1 BoTte d'information du cache de la page apres sa mise en cache 

Cette boite donne de precieuses informations pour le debogage concer- 
nant la cle unique du cache, sa duree de vie ou encore son age. En rafrai- 
chissant la page une nouvelle fois dans le navigateur, la boite 
d'information du cache passe du bleu au jaune, ce qui indique que la 
page a ete directement retrouvee dans le cache du serveur de fichiers. 
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Figure 20-2 BoTte d'information du cache de la page apres sa recuperation depuis le cache 



II faut aussi remarquer qu'aucune requete SQL a la base de donnees ha 
ete realisee dans cette seconde generation de la page d'accueil. La barre 
de debogage de Symfony est presente pour en temoigner. 

Principe de fonctionnement du cache de Symfony 

Lorsqu'une page est « cachable » et que le fichier de cache de cette der- 
niere n'existe pas encore sur le serveur, Symfony se charge de sauvegarder 
automatiquement l'objet de la reponse dans le cache a la fin de la requete. 
Pour toutes les requetes suivantes, Symfony renverra la reponse deja 
cachee sans avoir a appeler le controleur. Le schema ci-dessous illustre le 
cycle de fonctionnement d'une page destinee a une mise en cache. 



A RETENIR Mise en cache de la page 
d'accueil en fonction de la langue 

Meme si la langue peut etre modifiee simplement 
par I'utilisateur, le cache continuera de fonc- 
tionner, etant donne que celle-ci est directement 
embarquee dans I'URL. 
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Figure 20-3 

Schema de description du cycle 
de mise en cache d'une page 




A RETENIR Fonctionnement du cache 
avec les methodes HTTP 

Une requete entrante contenant des parametres 
GET ou soumise a partir des methodes POST, 
PUT ou DELETE, ne sera jamais mise en cache 
par Symfony, quelle que soit la configuration. 



Ce systeme a un impact positif immediat sur les performances de la 
page. Pour s'en convaincre, des outils Open Source comme le celebre 
JMeter (http://jakarta.apache.org/jmeter/) pour Apache permettent de 
mesurer les temps de reponse de chaque requete afin de generer des sta- 
tistiques. 

Activer le cache de la page de creation d'une nouvelle offre 

Au meme titre que la page d'accueil de Jobeet, la page de creation d'une 
nouveile offre d'emploi du module sflobeetJob peut etre mise en cache 
en specifiant la configuration suivante dans le fichier cache. yml. 

Configuration de la mise en cache de la page de creation d'une offre dans le fichier 
plugins/sfJobeetJob/modules/sfJobeeUob/config/cache.yml 

new: 

enabled: on 

i ndex: 

enabled: on 

all : 

with_layout: true 

Comme les deux pages peuvent etre mises en cache avec le layout, la 
directive de configuration with_layout a ete mutualisee dans la section 
all afin quelle s' applique a toutes les pages du module sfDobeetlob. 



Nettoyer le cache de fichiers 

Pour nettoyer tout le cache des pages HTML, il suffit d'executer la com- 
mande cache: clear de Symfony comme cela a deja ete utilise a maintes 
reprises tout au long de cet ouvrage. 

| $ php symfony cc 
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La tache automatique cache: clear supprime tous les fichiers de cache 
de Symfony qui se trouvent dans le repertoire cache/ du projet. Pour 
eviter de supprimer l'integralite du cache, cette commande est accompa- 
gnee de quelques options qui lui permettent de supprimer selectivement 
certaines parties du cache. Par exemple, pour ne supprimer que les tem- 
plates mis en cache pour l'environnement cache, il existe les deux 
options --type et --env. 

$ php symfony cc --type=template --env=cache 



Au lieu de nettoyer le cache a chaque fois qu'un changement est realise, 
il est possible d'annuler la mise en cache en ajoutant simplement une 
chaine de requete dans FURL, ou en utilisant le bouton Ignore cache de 
la barre de debogage de Symfony. 



Sf 



Jobeet 



co-f g 



Figure 20-4 Gestion du cache depuis la barre de deboguage de Symfony 



Activer le cache uniquement pour le resultat d'une action 
Exclure la mise en cache du layout 

II arrive parfois qu'il soit impossible de mettre en cache la page entiere, 
alors que le template evalue d'une action peut lui-meme etre mise en 
cache. Dit d'une autre maniere, il s'agit en fait de tout cacher a 1' excep- 
tion du layout. 

Pour l'application Jobeet, le cache des pages entieres est impossible en 
raison de la presence de la barre d'historique de consultation des dernieres 
offres d'emploi de l'utilisateur. Cette derniere varie en effet constamment 
de page en page. Par consequent la parametrage du cache doit etre mis a 
jour en desactivant la directive de configuration propre au layout. 

Suppression de la mise en cache du layout pour toutes les actions du module 
sfJobeetJob dans le fichier plugins/sfJobeetJob/modules/sfJobeetJob/config/cache.yml 

new: 

enabled: on 

i ndex : 

enabled: on 



all : 

withMayout: false 



La desactivation de la mise en cache du layout dans la directive de confi- 
guration wi th_l ayout necessite de reinitialiser tout le cache de Symfony. 

$ php symfony cc 

L'actualisation de la page dans le navigateur suffit alors pour constater la 
difference. 



Jobeet 








1 




Enter some keywords (city, country, position, ...) 



Recent viewed jobs: Web Designer - Extreme Sensio 



1 






S FEED 


Paris, France 


Web Designer 


i Extreme Sensio 




PROGRAMMING 




ffl FEED 


Paris, France 


Web Developer 


Company 12S 

J 



Figure 20-5 Mise en cache du resultat d'une action sans le layout 

Fonctionnement de la mise en cache sans layout 

Bien que le flux de la requete soit a peu pres similaire a celui de ce 
schema simplifie, il n'en demeure pas moins que la mise en cache des 
pages sans layout consomme davantage de ressources. En effet, la page 
cachee n'est plus renvoyee immediatement si elle existe car elle doit 
d'abord etre decoree par le layout, ce qui genere une perte notable de 
performance par rapport a la mise en cache globale. 



show: 
enabled: on 
with_layout : false 




Figure 20-6 Cycle de fonctionnement d'une page cachee sans son layout 
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Activer le cache des templates partiels et des composants 



Configuration du cache 

II est bien souvent impossible de cacher la globalite du resultat d'un tem- 
plate evalue par une action pour les sites hautement dynamiques. En 
effet, les templates d'action peuvent embarquer des entites dynamiques 
supplementaires telles que les templates partiels ou les composants qui 
reagissent differemment en fonction de l'utilisateur courant ou des para- 
metres qui leur sont affectes. 
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Figure 20-7 Mise en cache des templates partiels et des composants 

Par consequent, il est necessaire de trouver un moyen de configurer le 
cache au niveau de granularite le plus fin. Fort heureusement dans Sym- 
fony, les templates partiels et les composants peuvent etre caches de 
maniere independante. La capture d'ecran ci-dessus temoigne de la mise 



A RETENIR Deactivation automatique 
de la mise en cache du layout 

Configurer le cache pour un template partiel ou un 
composant est aussi simple que d'ajouter une nou- 
velle entree du meme nom que le template au 
fichier cache. yml. Pour ces types de fichier, 
I'option with_layout est volontairement sup- 
primee et non prise en compte par Symfony ; cela 
n'aurait en effet aucun sens. 



en cache du template partiel _1 i st . php qui genere la liste dynamique des 
offres d'emploi, ainsi que du composant de changement manuel de la 
langue du site dans le pied de page du layout. 

II convient done de configurer la mise en cache du composant de chan- 
gement de langue en creant un nouveau fichier cache. yml dans le 
module sf JobeetLanguage. Le code ci-dessous en presente le contenu. 

Configuration du cache pour le composant language dans le fichier plugins/ 
sfJobeetJob/modules/sfJobeetLanguage/config/cache.yml 

Janguage: 
enabled: on 

Principe de fonctionnement de la mise en cache 

Le nouveau schema ci-dessous decrit la strategic de mise en cache des 
templates partiels et des composants dans le flux de la requete. 



Important Contextuel ou non ? 



Le meme composant ou template partiel peut etre appele par differents templates. C'est le cas 
par exemple du partiel _1 i st . php de generation de la liste des offres d'emploi qui est uti- 
lise a la fois dans les modules sf JobeetJob et sf JobeetCategory. Comme le rendu 
de ce template est toujours le meme, le partiel ne depend done pas du contexte dans lequel il 
est utilise et le cache reste le meme pour tous les templates (le cache d'un fichier est evidem- 
ment systematiquement unique pour un jeu de parametres differents). 
Neanmoins, il arrive parfois que le rendu d'un partiel ou d'un composant soit different, en 
fonction de Taction qui I'inclut (dans le cas, par exemple, de la barre laterale d'un blog qui est 
legerement differente pour la page d'accueil et pour la page d'un billet). Dans ces cas-la, le 
partiel ou le composant est contextuel, et le cache doit etre configure en consequence en 
parametrant I'option contextual a la valeur true. 
_sidebar: 

enabled: on 

contextual : true 



list: 

enabled: on 



language: 
enabled: on 



Figure 20-8 

Schema de description de la mise en cache 
des partiels et des composants 
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Activer le cache des formulaires 



Comprendre la problematique de la mise en cache des formulaires 

Sauvegarder la page de creation d'une nouvelle offre dans le cache pose 
un veritable probleme etant donne que cette derniere contient un formu- 
laire. Pour mieux comprendre de quoi il s'agit, il est necessaire de se 
rendre sur la page Post a Job avec le navigateur pour generer et mettre la 
page en cache. Une fois cette etape realisee, les cookies de session du 
navigateur doivent etre reinitialises, et la page rafraichie. A present, la 
tentative de soumission du formulaire provoque une erreur globale aler- 
tant d'une eventuelle attaque CSRF. 



Jobeet 



» 




Enter some keywords (city, country, position, ...) 



Recent viewed jobs: 



NEW JOB 



csrf token: CSRF attack detected 
Category Dt-sign 
Type 



© Full time - Part time 



Freelance 

Figure 20-9 Resultat d'une attaque CSRF dans le formulaire de creation d'une nouvelle offre 



Que s'est-il passe exactement ? La reponse est simple. En effet, a la crea- 
tion de Implication dans les premiers chapitres, un mot de passe CSRF 
a ete defini pour securiser 1' application. Symfony se sert de ce mot de 
passe pour generer et embarquer un jeton unique dans tous les formu- 
laires. Ce jeton est genere pour chaque utilisateur et chaque formulaire, 
et protege I'application d'une eventuelle attaque CSRF. 

La premiere fois que la page est affichee, le code HTML du formulaire 
est genere et stocke dans le cache avec le jeton unique de 1'utilisateur 
courant. Si un nouvel utilisateur arrive juste apres avec son propre jeton, 
ce sera malgre tout le resultat cache avec le jeton du premier utilisateur 
qui sera affiche. A la soumission du formulaire, les deux jetons ne corres- 
pondent pas et la classe du formulaire lance une erreur. 
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Desactiver la creation du jeton unique 

Comment ce probleme peut-il etre resolu, alors qu'il est legitime de vou- 
loir sauvegarder le formulaire dans le cache ? Le formulaire de creation 
d'une nouvelle offre ne depend pas de l'utilisateur et ne change absolu- 
ment rien pour l'utilisateur courant. Dans ce cas, aucune protection CSRF 
n'est necessaire et la generation du jeton peut tout a fait etre supprimee. 

Suppression du jeton CSRF du formulaire de creation d'une nouvelle offre dans le 
fichier plugins/sfJobeetPlugin/lib/form/doctrine/PluginJobeetJobForm.class.php 

! abstract PI ugi nJobeetJobForm extends BaseJobeetJobForm 
{ 

public function construct(sfDoctri neRecord Sobject = null, 

' Soptions = arrayO , $CSRFSecret = null) 
{ 

parent:: construct($object , Soptions, false); 

} 

// ... 

} 

II ne reste alors plus qua vider le cache et reessayer le scenario precedent 
afin de prouver que tout fonctionne correctement. La meme configura- 
tion doit egalement etre etendue au formulaire de modification de la 
langue du site, puisque celui-ci est contenu dans le layout et sera sauve 
dans le cache. Comme la classe par defaut sfLanguageForm est utilisee et 
qu'il n'est pas necessaire de creer une nouvelle classe, la desactivation du 
jeton CSRF peut etre realisee depuis l'exterieur de la classe dans Taction 
et le composant du module sf JobeetLanguage. 

Desactivation du jeton CSRF depuis le composant language du fichier plugins/ 
sfJobeeUob/modules/sfJobeetLanguage/actions/components.class.php 

class sfJobeetLanguageComponents extends sfComponents 
{ 

public function executeLanguage(sfWebRequest Srequest) 
{ 

$this->form = new sfForml_anguage($thi s->getUser() , 
array( ' 1 anguages ' => array('en', 'fr'))); 

unset ($thi s->form [$thi s->form->getCSRFFiel dNameC)] ) ; 

} 

} 

Desactivation du jeton CSRF depuis I'action changeLanguage du fichier plugins/ 
sfJobeetJob/modules/sfJobeetLanguage/actions/actions.class.php 

class sfJobeetLanguageActions extends sfActions 
{ 

public function executeChangel_anguage(sfWebRequest Srequest) 



{ 

$form = new sf Forml_anguage($thi s->getUser() , 

array( 1 1 anguages ' => array('en', 'fr'))); 
unset ($form [$form->getCSRFFi el dName()] ) ; 

// ... 

} 

} 

La methode getCSRFFieldNameO retourne le nom du champ qui con- 
tient le jeton CSRF. En supprimant ce champ, le widget et le validateur 
associes sont automatiquement retires du processus de generation et de 
controle du formulaire. 

Retirer le cache automatiquement 

Configurer la duree de vie du cache de la page d'accueil 

Chaque fois que l'utilisateur poste et active une nouvelle offre, la page 
d'accueil de Jobeet doit etre rafraichie pour afficher la nouvelle annonce 
dans la liste. Neanmoins, il n'est pas urgent de la faire apparaitre en 
temps reel sur la page d'accueil, c'est pourquoi la meilleure strategic con- 
siste a diminuer la duree de vie du cache a une periode acceptable. 

Configuration de la duree de vie du cache de la page d'accueil dans le fichier plugins/ 
sfJobeetJob/modules/sfJobeeUob/config/cache.yml 

index: 

enabled: on 
lifetime: 600 

Au lieu d'affecter la duree de vie par defaut d'une journee a cette page, le 
cache sera automatiquement supprime et regenerer toutes les dix minutes. 

Forcer la regeneration du cache depuis une action 

Toutefois, s'il est veritablement necessaire de mettre a jour la page 
d'accueil des que l'utilisateur active sa nouvelle offre, il faut alors modi- 
fier Taction executePubl i sh() du module sf JobeetJob afin de forcer 
manuellement le cache. 

Regeneration manuelle du cache depuis une action dans le fichier plugins/ 
sfJobeetJob/modules/sfJobeetJob/actions/actions.class.php 

public function executePublish(sfWebRequest Srequest) 
{ 

$request->checkCSRFProtection() ; 



$job = $this->getRoute()->getObjectO ; 
$job->publish() ; 

if ($cache = $this->getContext()->getViewCacheManagerO) 
{ 

$cache->remove( ' sf JobeetJob/index?sf cul ture=* ' ) ; 
$cache->remove(' sf JobeetCategory/show?id=' 

.$job->getJobeetCategory()->getId()) ; 

} 

$this->getUser()->setFlash('notice' , sprintf ('Your job is now 
online for %s days.', sfConfig: :get('app_active_days'))) ; 

$this->redi rect($thi s->generateUrl ( ' job_show_user ' , $job)) ; 

} 

Le cache des pages HTML est exclusivement gere par la classe 
sfViewCacheManager. La methode remove () supprime le cache associe a 
une URL interne. Pour retirer le cache pour toutes les valeurs possibles 
d'une variable, il suffit de specifier le caractere etoile * comme valeur. 
Ainsi, l'utilisation de la chaine sf_cu"lture=* dans le code ci-dessus 
signifie que Symfony supprimera le cache pour les pages d'accueil de 
Jobeet en francais et en anglais. 

Comme le gestionnaire de cache est nul lorsque le cache est desactive, la 
suppression du cache a ete encapsulee dans un bloc conditionnel. 

AVERTISSEMENT La classe sfContext 

L'objet sfContext contient toutes les references aux objets du noyau de Symfony comme la 
requete, la reponse, I'utilisateur, etc. Puisque la classe sfContext agit comme un singleton, 
il est possible d'avoir recours a I'instruction sfContext : : getlnstance() pour le recu- 
perer depuis n'importe ou et ensuite avoir acces a tous les objets metiers du noyau. 
Suser = sfContext: :getInstance()->getUser() ; 

Toutefois, il est bon de reflechir a deux fois avant de faire appel a 
sfContext: :getlnstance()dans les autres classes car cela engendre un couplage 
fort. II est toujours preferable de passer l'objet sfContext en parametre d'une classe qui en 
a besoin. 

II est egalement possible d'utiliser sfContext comme un registre pour y stacker des objets en 
utilisant la methode set(), qui prend un nom et un objet en guise de parametres. La methode 
get(), quanta elle, permet de recuperer un objet du registre par le biais de son nom. 
sfContext: :getlnstance()->set(' job' , $job) ; 
$job = sfContext: :getlnstance()->get(' job') ; 
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Tester le cache a partir des tests fonctionnels 
Activer le cache pour 1'environnement de test 

Avant de demarrer l'ecriture de nouveaux tests fonctionnels, la configu- 
ration de 1'environnement de test doit etre mise a jour afin d'activer la 
couche de cache des pages HTML. Le code ci-dessous indique les 
modifications a realiser dans le fichier de configuration setti ngs . yml de 
l'application frontend. 

Activation du cache pour 1'environnement de test dans le fichier apps/frontend/ 
config/settings.yml 

test: 

. setti ngs : 

error_reporti ng : <?php echo ((E_ALL | E_STRICT) a 
E_N0TTCE) ."\n" ?> 

cache: on 
web_debug: off 
etag: off 



Tester la mise en cache du formulaire de creation d'une offre 
d'emploi 

La derniere etape consiste a mettre a jour la suite de tests fonctionnels afin 
de verifier que les pages de Jobeet configurees tout au long de ce chapitre 
sont correctement mises en cache par le serveur. Puisqu'il a beaucoup ete 
question de la page de creation d'une nouvelle annonce, les tests suivants 
controlent que cette derniere est bien cachee automatiquement. 

Test de la mise en cache de la page de creation d'une nouvelle offre dans le fichier 
test/functional/frontend/jobActionsTest.php 

$browser-> 

info(' 7 - Dob creation page')-> 

get('/fr/')-> 

wi th ( ' vi ew_cache 1 ) ->i sCached (t rue , f al se) -> 

createJob(array( 1 category_i d ' => 
Doctri ne : : getTabl e( 'CategoryTransl ati on ' ) 

->f i ndOneBySl ug ( ' prog rammi ng ' ) ->getld () ) , true) -> 

get('/fr/')-> 

wi th ( ' vi ew cache ' ) ->i sCached(t rue , f al se) -> 

wi th( ' response ' ) ->checkEl ement( ' . category_prog rammi ng 
.more_jobs', '/23/') 
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ASTUCE Tester I'environnement de test 
dans un navigateur 

Meme avec tous les outils fournis par le fra- 
mework de tests fonctionnels, il est parfois plus 
facile de diagnostiquer des problemes a travers le 
navigateur. C'est vraiment tres simple a mettre en 
ceuvre puisqu'il suffit de creer un controleur 
frontal pour I'environnement de test. Les traces de 
logs sauvegardes dans le fichier log/ 
frontend_test.log apportent de nom- 
breuses informations utiles pour le debogage. 



Le testeur view_cache est employe ici pour verifier ce qui figure dans le 
cache par le biais de la methode f sCachedO qui accepte deux valeurs 
booleennes en parametres : 

• la premiere pour determiner si oui ou non la page doit etre dans le 
cache ; 

• la seconde pour determiner si oui ou non la page cachee comprend le 
layout. 



En resume... 

Comme la plupart des autres fonctionnalites de Symfony, le sous-fra- 
mework natif de cache est particulierement flexible puisqu'il permet au 
developpeur de configurer le cache des fichiers au niveau de granularite 
le plus fin. Cette gestion poussee du cache des pages HTML offre 
l'avantage de personnaliser les strategies de mise en cache aussi bien de 
maniere globale pour un ensemble de fichiers et d'actions, que de 
maniere individualisee. 

Le prochain chapitre acheve la realisation de cette etude de cas Jobeet en 
s'interessant a la toute derniere etape du developpement d'une applica- 
tion Internet : le deploiement en production. Cette etape est particulie- 
rement decisive et merite toutes les attentions de la part du developpeur. 
Le chapitre traitera de configuration, d'initialisation et de securisation 
de I'application, mais egalement de la personnalisation des pages 
d'erreur 404 et 500, de l'activation d'un cache d'opcodes et bien evidem- 
ment du deploiement des fichiers source sur le serveur de production. 
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chapitre 




Le deploiement en production 



MOTS-CLES 



Apres les nombreuses heures passees en developpement, 
puis en environnement de recette, la derniere etape decisive 
de creation d'une application web est bien evidemment 
le deploiement sur le serveur de production final. Cette etape 
est cruciale car elle implique de parametrer soigneusement 
le serveur et le projet Symfony afin d'eviter toute faille 
de securite ou dysfonctionnement. 

Heureusement, le framework Symfony dispose d'outils 
qui facilitent ces phases de deploiement critiques. 



► Accelerateur PHP APC 

► Personnalisation des erreurs 4 

► Deploiement via rsync 



Le chapitre precedent a ete l'occasion de preparer le terrain en configurant 
pas a pas le cache des pages HTML de l'application Jobeet pour l'environ- 
nement de production. Par consequent, la derniere etape du projet consiste 
a deployer les fichiers source vers le serveur de production final. 

Tout au long de ces vingt et un chapitres, l'application a ete construite 
sur une machine de developpement, probablement un serveur web local 
personnel pour la plupart des developpeurs... A present, le moment est 
venu de deplacer tout le site sur le serveur de production afin de le rendre 
disponible aux internautes. Cependant, la mise en production d'une 
application n'est jamais aussi simple quelle n'y parait. II faut en effet 
penser a preparer et parametrer plusieurs composants, a commencer par 
le serveur web. Ce dernier chapitre se consacre done entierement a ce 
sujet afin de presenter quelles sortes de strategies de deploiement 
employer, quelles methodologies suivre ou bien encore quels outils 
mettre en place pour faciliter et reussir un deploiement... 



Preparer le serveur de production 



Information 

Acces SSH en ligne de commande 

La majorite de ce chapitre fait usage de la ligne 
de commande par le biais d'un tunnel SSH entre 
la machine locale et le serveur web distant. Si 
votre serveur web ne supporte pas les con- 
nexions SSH, ou plus generalement si I'acces en 
ligne de commande est interdit, alors vous 
pouvez sauter les sections pour lesquelles ces 
outils sont necessaires. 



Le premier element cle du processus de deploiement d'un projet est bien 
sur le serveur web car c'estlui qui accueille l'application. Son installation 
et par extension, sa configuration, doivent le rendre capable d'interpreter 
les fichiers source du site web. Par consequent, la machine doit au 
minimum disposer d'un serveur web (Apache 2), d'un serveur de bases 
de donnees (MySQL) et d'une version de PHP recente, e'est-a-dire 
strictement superieure ou egale a la 5.2.4. Ces trois outils forment le 
tierce de base d'une plate-forme LAMP destinee a recevoir une applica- 
tion web. 

Linstallation de ces logiciels n'etant pas le sujet principal de cet ouvrage, 
la suite du chapitre considere qu'ils sont correctement installes sur le ser- 
veur de production. Quant a la configuration du serveur web Apache, 
elle a ete largement traitee au premier chapitre. 

Verifier la configuration du serveur web 

Tout d'abord, il est primordial de verifier que PHP est installe sur le ser- 
veur web avec toutes les extensions necessaires, et qu'il est bien sur confi- 
gure convenablement (magic_quotes_gpc a off, register_g"lobals a 
off...). De la meme maniere qu'au tout premier chapitre de cet ouvrage, 
e'est le script check_configuration.php fourni par Symfony qui sera 
employe pour controler la configuration globale du serveur. Etant donne 
que Symfony n'est pas encore installe par defaut sur la machine de pro- 
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duction, ce script PHP doit d'abord etre recupere depuis les sources du 
framework, et ensuite installe sur le serveur web. 

http://trac.symfony-project.Org/browser/branches/1.2/data/bin/ 
check_configuration.php?format=raw 

II suffit alors de copier et de coller le fichier a la racine du serveur de pro- 
duction, puis de l'executer depuis un navigateur, mais egalement en ligne 
de commande afin de s' assurer que les deux environnements sont confi- 
gures de la meme maniere pour Symfony. 

| $ php check_configuration.php 

L'objectif de ce fichier est d'aider a deceler les defauts de configuration 
de la plate-forme PHP ou les extensions obligatoires manquantes 
comme les drivers PDO, le support du XML ou encore les fonctions de 
conversion d'encodage. A l'execution de ce script, si des erreurs sont 
revelees, il est important de les corriger une par une, puis de relancer le 
script obligatoirement dans les deux environnements. 

Installer I 'accelerateur PHP APC 

Pour le serveur de production, il est evident qu'il faut obtenir les meilleures 
performances possibles, et l'installation d'un accelerateur PHP y contribue 
pour beaucoup en apportant les meilleures ameliorations gratuitement. 
Pour le langage PHP, de nombreuses solutions Open Source eprouvees 
existent comme APC, eAccelerator ou encore Turck MMCache. La 
societe Zend propose quant a elle une solution payante toute aussi perfor- 
mante. Comme APC est l'une des solutions les plus populaires et qu'il sera 
aussi livre par defaut a la sortie de PHP 6, c'est lui qui a ete choisi pour 
ameliorer les performances de PHP. Son installation est particulierement 
simple puisqu'elle se resume a l'execution d'une seule commande. 

j $ peel install APC 

L'installation d'APC depend du systeme d'exploitation installe, c'est 
pourquoi il n'est pas a exclure que des dependances supplementaires 
pour ce dernier puissent etre installees. 

Installer les librairies du framework Symfony 
Embarquer le framework Symfony 

L'une des forces majeures de Symfony est la complete autonomic du 
projet. En effet, tous les fichiers necessaires au bon fonctionnement du 
projet se trouvent a la racine du repertoire principal de ce dernier. Par 



Technology Comment fonctionne 
un accelerateur PHP ? 

Un accelerateur PHP est un logiciel qui se charge 
de mettre en cache le code precompile, I'opcode et 
des scripts PHP afin d'eviter le temps supplemen- 
taire d'interpretation et de precompilation du code 
source a chaque requete. Les performances sont 
au rendez-vous puisque Ton constate generale- 
ment un gain de I'ordre de 100 % voire plus, soit 
plus du double des performances sans accelerateur 
PHP. Pour en savoir plus au sujet d'APC, la docu- 
mentation officielle du projet se trouve a I'adresse 
http://www.php.net/manual/en/ 
apc.configuration.php. 
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consequent, le projet peut etre deplace facilement d'un repertoire a un 
autre sans que Ton ait a modifier quoique ce soit, grace notamment a 
l'utilisation de chemins relatifs par Symfony. Cela signifie aussi que le 
repertoire du serveur de production ne doit pas etre necessairement le 
meme que celui qui se trouve sur la machine de developpement. 

Le seul chemin absolu potentiel que Ton peut trouver figure dans le 
fichier config/ProjectConfiguration. class. php ; mais le chapitre 1 a 
permis d'y faire attention et de le remplacer par un chemin relatif Nean- 
moins, si ce n'etait pas encore le cas, ce chemin absolu vers le composant 
interne de chargement automatique des classes de Symfony peut etre 
transforme en chemin relatif de la maniere suivante. 

Transformation du chemin absolu vers la classe sfCodeAutoload en chemin relatif 
dans le fichier config/ProjectConfiguration.class.php 

requi re_once ch'rname( FILE ). '/■ ■ /l i b/vendor/symfony/1 i b/ 

autol oad/sf CoreAutol oad . cl ass . php ' ; 

Garder Symfony a jour en temps reel 

Bien que le projet et le framework soient entierement autonomes, il est aise 
de maintenir Symfony a jour a la sortie de nouvelles versions mineures. 

Malgre tout le soin apporte au developpement du framework, l'equipe de 
Symfony corrige continuellement des bogues et parfois des failles de secu- 
rite avant de les publier a l'occasion de la sortie d'une nouvelle version 
mineure. Par consequent, il est possible de garder la version de Symfony a 
jour en temps reel pour n'importe quelle application en production. 

L'avantage avec le projet Symfony, c'est que toutes les versions majeures 
(1.0, 1.1 et 1.2) du framework sont maintenues au moins un an, et pen- 
dant ces periodes de maintenance, aucune nouvelle fonctionnalite n'est 
ajoutee mais uniquement des correctifs. Cette approche permet ainsi de 
conserver une stabilite du framework et de toujours garantir un pro- 
cessus de mise a jour rapide, securise et sans risque d'une version 
mineure a une autre. 

Mise a jour manuelle de Symfony depuis I'archive ZIP 

Mettre a jour Symfony est extremement simple puisqu'il suffit de modi- 
fier le contenu du repertoire lib/vendor/symfony/ du projet. Ainsi, si 
Symfony a ete installe depuis I'archive ZIP, le contenu de la nouvelle 
archive (nouvelle version) peut alors etre decompresse dans ce repertoire 
pour remplacer les fichiers source existants. 



Mise a jour de Symfony a I'aide de Subversion 

Les utilisateurs de Subversion prefereront certainement mettre a jour 
leur version de Symfony pour chacun de leur projet en liant cet outil au 
dernier tag Symfony 1.2. 

$ svn propedit svn : external s lib/vendor/ 

# symfony http://svn.symfony-project.com/tags/RELEASE_l_2_l/ 

Mettre a jour Symfony est ensuite aussi simple que de changer le tag de 
la toute derniere version du framework disponible sur le depot Subver- 
sion du projet. Une autre approche consiste a installer les fichiers source 
de Symfony comme des ressources externes a I'aide de la propriete 
svn: externals de Subversion. Cette methode a l'avantage de faire pro- 
fiter le developpeur de la toute derniere version de developpement de 
Symfony a jour, a chaque fois qu'il execute la commande svn upragde. 

$ svn propedit svn : external s lib/vendor/ 

# symfony http://svn.symfony-project.eom/branches/l.2/ 

Lorsque Symfony est mis a jour, il est recommande de toujours nettoyer 
le cache, et tout particulierement en environnement de production etant 
donne que de nouvelles classes peuvent etre ajoutees au framework. 

| $ php symfony cc 

Basculer d'une version de Symfony a une autre facilement 

II arrive parfois que les developpeurs veuillent tester une nouvelle version 
de Symfony sans avoir a remplacer celle qui existe deja pour le projet ; 
l'objectif etant bien sur de pouvoir revenir en arriere facilement si cela ne 
convient pas. 

Pour y parvenir, il suffit simplement de telecharger les fichiers source de 
Symfony dans un autre repertoire du projet (lib/vendor/symfony_test/ 
par exemple), puis de modifier le chemin relatif dans la classe de confi- 
guration ProjectConfiguration, et enfin de proceder au nettoyage du 
cache. Finalement, pour revenir en arriere, la tache est aussi simple : ree- 
diter le chemin relatif dans la classe de configuration du projet, sup- 
primer le repertoire des sources de Symfony, et enfin regenerer le cache. 



ASTUCE Nettoyer le cache manuellement 
sans passer par la ligne de commande 

Lorsque I'acces au serveur de production est 
impossible depuis SSH, la seule solution pour 
simuler le nettoyage du cache est de se connecter 
a I'aide d'un client FTP, puis de supprimer manuel- 
lement tous les repertoires qui se trouvent dans le 
repertoire cache/ du projet. 
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Personnaliser la configuration de Symfony 



Configurer 1'acces a la base de donnees 

La plupart du temps, la base de donnees du serveur de production dis- 
pose de droits d'acces differents de celle installee localement. II est done 
necessaire de mettre a jour ces droits pour 1'environnement de produc- 
tion en utilisant notamment la commande configure: database. Cette 
tache automatique a deja ete utilisee au troisieme chapitre pour initia- 
liser les codes d'acces aux deux bases de donnees de Jobeet. 

$ php symfony configure: database 

"mysql :host=localhost;dbname=prod_dbname" prod_user prod_pass 

Cette tache se contente simplement d'ecrire les nouveaux identifiants de 
connexion a la base de donnees de production directement dans le fichier 
de configuration databases. yml. L'utilisation de l'interface en ligne de 
commande n'est bien sur pas obligatoire, et le fichier databases . yml peut 
aussi etre edite manuellement dans un editeur de texte. 

Generer les liens symboliques pour les ressources web 

Comme l'application Jobeet utilise des plug-ins qui embarquent des res- 
sources web (assets), certains liens symboliques doivent etre recrees afin 
de rendre ces fichiers disponibles depuis un navigateur web. Heureuse- 
ment, la tache pi ugi n : publ i sh-assets est faite specialement pour 5a car 
elle permet de regenerer ces liens symboliques, ou de les creer si les plug- 
ins n'ont pas ete installes a partir de la commande pi ugi n : i nstal 1 . 

$ php symfony pi ugi n : publ i sh-assets 

Personnaliser les pages d'erreur par defaut 

Remplacer les pages d'erreur interne par defaut 

Avant de basculer les fichiers sur le serveur de production, il est preferable 
de personnaliser certaines pages par defaut de Symfony comme la page 
d'erreur 404 « Page non trouvee » ou encore la page d'erreur 500 
lorsqu'une erreur interne se produit notamment par le biais des exceptions. 

Les pages d'erreur pour le format YAML ont deja ete configurees au 
chapitre 15 sur les services web en creant les nouveaux fichiers 
error .yaml .php et exception .yaml . php dans le repertoire conf ig/error/. 
Le fichier error. yaml .php est utilise par Symfony en environnement de 



production tandis que le fichier exception.yaml .php sert pour l'environ- 
nement de developpement. Les pages d'erreur pour le format HTML 
sont personnalisables en procedant de la meme maniere, c'est-a-dire en 
creant deux fichiers config/error/error. html .php et config/error/ 
excepti on . html . php. 

Personnaliser les pages d'erreur 404 par defaut 

La page d'erreur 404 (« Page non trouvee ») peut egalement etre person- 
nalisee en changeant les valeurs des directives de configuration 
error_404_action et error_404_modul e du fichier settings. yml de 
l'application. 

Modification des pages d'erreur 404 par defaut de Symfony dans le fichier apps/ 
frontend/config/settings.yml 

all : 

.actions: 
error_404_module: default 
error_404_action: error404 

Personnaliser la structure de fichiers par defaut 

Nombreux sont les prestataires d'hebergement qui imposent des restric- 
tions sur leurs plates-formes d'hebergement, en particulier sur les ser- 
veurs mutualises pour des raisons de securite. Ces restrictions impactent 
generalement la configuration de PHP ainsi que le nom du repertoire 
qui represents la racine web, et qui ne peut etre modifie. 

Modifier le repertoire par defaut de la racine web 

II arrive par convention que ce repertoire soit nomme publicjitml/ ou 
www/ au lieu de web/, ce qui rend impossible le fonctionnement de Sym- 
fony. Heureusement, la classe ProjectConfiguration du projet possede 
les methodes adequates pour redefinir les chemins de certains repertoires 
comme celui de la racine web. 

Modification du chemin vers la racine web dans le fichier config/ 
ProjectConfiguration.class.php 

class ProjectConfiguration extends sfProjectConfiguration 
{ 

public function setupO 
{ 

$this->setwebDir($this->getRootDir() . '/public html ') ; 

} 

} 



La methode setWebDi r() accepte en parametre le chemin absolu vers le 
repertoire qui sert de racine web. Si ce repertoire est deplace ailleurs, il 
ne faut pas oublier d'editer les scripts controleurs pour verifier que les 
chemins vers le fichier config/ProjectConfiguration. class. php sont 
toujours valides. 

requi re_once(di rname( FILE ) 

. '/■ ./config/ProjectConfiguration. class. php') ; 

Modifier les repertoires du cache et des logs 

Le framework Symfony n'ecrit que dans deux repertoires : cache/ et 
1 og/. Pour des raisons de securite evidentes, certains hebergeurs (les gra- 
tuits entre autres) n'activent pas les permissions d'ecriture dans le reper- 
toire principal mais parfois dans un autre qui se trouve en dehors. Si c'est 
le cas, alors ces deux repertoires peuvent etre deplaces en toute securite 
dans un endroit accessible en ecriture sur le systeme de fichiers. II suffit 
alors simplement d'indiquer a Symfony oil ils se situent sur ce dernier. 

Modification des chemins vers les repertoires de cache et de log de Symfony dans le 
fichier config/ProjectConfiguration.class.php 

class ProjectConfiguration extends sfProjectConfiguration 
{ 

public function setupO 
{ 

$thi s->setCacheDi r ( ' /tmp/symf ony cache ' ) ; 
$thi s->setLogDi r ( ' /tmp/symf ony 1 ogs ' ) ; 

} 

} 

De la meme maniere que la methode setWebDirO, les methodes 
setCacheDi r() et setLogDi r() prennent en parametre un chemin absolu 
vers les repertoires respectifs cache/ et log/. 

A la decouverte des factories 

Lensemble des pages de cet ouvrage a introduit petit a petit les differents 
objets du cceur de Symfony comme sfUser, sf Request, sf Response, 
sfI18N, sf Routing et bien d'autres encore. Ces objets sont automatique- 
ment crees, configures et geres par le framework Symfony. Ils sont de plus 
toujours accessibles depuis l'objet sfContext, et comme pour beaucoup de 
choses dans le framework, ils sont configurables par le biais d'un fichier de 
configuration encore non etudie jusqu'a maintenant : facto ries.yml. Ce 
fichier de configuration est lui aussi parametrable par environnement. 



Initialisation des objets du noyau grace a factories.yml 



Le fichier factories.yml decrit par environnement la configuration des 
differents objets du noyau qui doivent etre crees automatiquement par 
l'objet sfContext. En effet, lorsque l'objet sfContext initialise ses facto- 
ries, il lit le fichier factories.yml afin de connaitre quelles classes 
(class) il doit instancier et quels parametres (param) il doit passer au 
constructeur de chacune d'entre elles. 

Extrait de description de l'objet sfResponse dans le fichier de configuration apps/ 
frontend/config/factories.yml 

response: 

class: sfWebResponse 
param: 

send_http_headers : false 

Dans cet extrait de code YAML, pour creer l'objet de la reponse, Sym- 
fony instancie la classe sfWebResponse et passe a son constructeur la 
valeur de l'option send_http_header en guise de parametre. Etre capable 
de personnaliser soi-meme les factories signifie aussi que Symfony 
donne au developpeur la capacite de changer les objets utilises par defaut 
par le cceur de Symfony De la meme maniere, il est possible de modifier 
le comportement par defaut de ces classes en changeant les parametres 
qui leur sont envoyes. 

Les sections suivantes presentent quelques exemples typiques de person- 
nalisation de ces objets a l'initialisation de Symfony, et une annexe 
entiere est consacree en fin d'ouvrage a la description des differentes 
directives de configuration sur lesquelles il est possible d'agir. 

Modification du nom du cookie de session 

Pour reconnaitre et manipuler la session courante de l'utilisateur entre chaque 
page, Symfony utilise un cookie. Ce cookie possede un nom par defaut, qui 
peut bien evidemment etre change a l'aide du fichier facto ri es . yml . II suffit 
pour cela d'ajouter la configuration suivante au fichier sous la section al 1 
pour changer le nom du cookie de session de Jobeet. 

Modification du nom du cookie de session dans le fichier apps/frontend/config/ 
factories.yml 

storage : 

class: sfSessionStorage 
param: 

session name: jobeet 



Remplacer le moteur de stockage des sessions par une 
base de donnees 

Dans Symfony, la classe par defaut pour gerer la session de l'utilisateur 
courant est sfSessionStorage, qui est en realite une API orientee objet 
surchargeant le mecanisme natif des sessions de PHP. Par consequent, 
les informations de session des utilisateurs sont conservees sur le systeme 
de fichiers local. Or, il arrive tres souvent qu'il faille gerer les sessions des 
utilisateurs differemment, en ayant par exemple recours a une base de 
donnees dans laquelle tout est centralise. Grace aux factories et a la 
classe sf PDOSessionStorage, le mecanisme de gestion des sessions utili- 
sateurs est alors automatiquement deporte de maniere totalement trans- 
parente vers une table de la base de donnees. 

Configuration d'une base de donnees pour le stockage des sessions dans le fichier 
apps/frontend/config/factories.yml 

storage : 

class: sf PDOSessionStorage 
param: 

session_name: jobeet 

db table: session 

database: doctrine 

db id col : id 

db data col : data 

db time col : time 

La classe sf PDOSessionStorage accepte de nouveaux parametres dans 
son constructeur qui definissent respectivement : 

• le nom de la table dans laquelle sont stockees les sessions ; 

• le nom de la base de donnees qui heberge cette table ; 

• le nom de la colonne qui sert de cle primaire dans la table ; 

• le nom de la colonne de la table qui accueille les donnees de session 
serialisees ; 

• le nom de la colonne qui contient la date de derniere mise a jour de la 
session. 

Grace a ces cinq informations, le framework Symfony est capable de 
deporter la gestion des sessions vers une base de donnees. 

Definir la duree de vie maximale d'une session 

Toutes les sessions sont ephemeres et possedent done une duree de vie 
dans le temps. La duree de vie d'une session determine en realite le 
temps pendant lequel la session reste active entre deux pages consecu- 
tives. Si l'utilisateur passe d'une page a une autre dans un temps inferieur 



a celui de la duree de la session, alors sa session est perduree de ce meme 
laps de temps jusqu'a la page suivante, et ainsi de suite. 

En revanche, si le temps passe entre deux pages consecutives excede la 
valeur maximale, alors toutes les informations sont perdues ; la session 
est considered comme expiree et doit etre reinitialisee. Avec le fichier 
f acton' es.yml, la valeur de cet intervalle de validite de la session peut 
etre modifiee a l'aide de la directive de configuration ti meout qui fixe la 
duree a 1 800 secondes, soit 30 minutes. 

Modification de la duree de vie d'une session dans le fichier apps/frontend/config/ 
factories.yml 

user : 

class: myllser 
param: 

timeout: 1800 

Definir les objets d'enregistrement d'erreur 

Par defaut, l'enregistrement des erreurs en environnement de production 
est desactive en raison du nom de la classe du logger, sfNoLogger, 
comme le montre la configuration ci-dessous. 

Definition des objets de log d'erreur en environnement de production dans le fichier 
apps/frontend/config/factories.yml 

prod : 
logger: 

class: sfNoLogger 

param: 

level : err 
loggers: ~ 

Neanmoins, l'enregistrement des erreurs dans les fichiers de log du sys- 
teme de fichiers peut etre active en modifiant le nom de la classe par 
sfFileLogger par exemple. 

Activation des logs en environnement de production dans le fichier apps/frontend/ 
config/factories.yml 

logger: 

class: sfFileLogger 

param: 

1 evel : error 

file: %SF LOG DIR%/%SF APP% %SF ENVIRONMENTS . 1 og 



ASTUCE Utiliser des chemins absolus 
dans un fichier YAML 

Dans le fichier de configuration 
facto ri es . yml , les chaTnes %XXX% sont rem- 
placees par leur valeur equivalente dans I'objet 
global sfConfig. Par exemple, %SF_APP% 
dans un fichier de configuration YAML est similaire 
a I'appel a sfConfig: : get( ' sf_app ' ) 
dans du code PHP. Cette notation peut aussi etre 
utilisee dans le fichier de configuration app . yml . 
C'est particulierement utile lorsque Ton a besoin 
de referencer un chemin dans un fichier de confi- 
guration sans avoir a coder en dur ce chemin 
(SF_R00T_DIR, SF_WEB_DIR, etc.). 
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Deployer le projet sur le serveur de production 



Que faut-il deployer en production ? 

Le deploiement sur le serveur de production est la toute derniere etape 
avant que le projet ne demarre veritablement son cycle de vie sur 
Internet. Cette procedure est capitale car il est important de faire atten- 
tion a ne pas deployer de fichiers inutiles ou ecraser des donnees exis- 
tantes envoyees par les utilisateurs comme les logos des societes. 

Dans un projet Symfony, trois repertoires sont a exclure au moment du 
transfert des fichiers sur le serveur de production : cache/, log/ et web/ 
uploads/. Tous les autres fichiers peuvent etre transferes tels quels. 
Neanmoins, pour des raisons de securite evidentes, il convient de ne pas 
transferer les controleurs frontaux non destines a l'environnement de 
production comme les fichiers f rontencLdev.php, backend_dev. php et 
f rontend_cache . php. 

Mettre en place des strategies de deploiement 

Cette section explique comment automatiser et faciliter le deploiement 
d'une application vers un serveur de production. Par consequent, il est 
absolument necessaire d'avoir les pouvoirs requis sur le serveur de pro- 
duction afin d'y acceder par l'intermediaire d'une connexion SSH. Si en 
revanche Faeces au serveur est restreint a un compte FTP, la seule solu- 
tion possible de deploiement consistera a transferer manuellement tous 
les fichiers a chaque fois qu'un nouveau processus de deploiement 
entrera en jeu. 

Deploiement a I'aide d'une connexion SSH et rsync 

Avec Symfony, la maniere la plus simple de deployer une application 
web est d'utiliser la commande integree project: deploy qui fait appel 
aux clients SSH et rsync pour se connecter au serveur et transferer les 
fichiers d'un ordinateur a un autre. Cependant, 1'utilisation de cette 
tache automatique requiert la configuration des parametres de con- 
nexion au serveur de production a l'interieur du fichier config/ 
properties.ini. Ce fichier de configuration est capable de definir plu- 
sieurs serveurs representes par les sections entre crochets. Dans le cadre 
de Jobeet, seul un serveur de production est necessaire. 



Parametrage des identifiants de connexion au serveur de production dans le fichier 
config/properties.ini 



[production] 

host=www . j obeet . o rg 

port=22 

user=jobeet 

di r=/var/www/jobeet/ 

type=rsync 

pass= 

Une fois les parametres du serveur etablis, l'application peut etre 
deployee a l'aide de la commande project: deploy. 

j $ php symfony project:deploy production 

En realite la commande precedents ne fait que simuler le transfert. Pour 
lancer veritablement le deploiement des fichiers sur le serveur de pro- 
duction, l'option --go doit etre ajoutee explicitement. 

| $ php symfony project:deploy production — go 

Configurer rsync pour exclure certains fichiers du deploiement 

Par defaut, Symfony ne transferers ni les repertoires ni les controleurs 
frontaux sensibles de developpement mentionnes dans la section prece- 
dente. C'est en effet parce que la tache project: deploy exclut automati- 
quement du processus de deploiement les fichiers et dossiers configures 
dans le fichier config/rsync_exclude.txt. 

Configuration des fichiers et repertoires a exclure du deploiement dans le fichier 
config/rsync_exclude.txt 

. svn 

/web/uploads/* 

/cache/* 

/log/* 

/web/*„dev.php 

L'application Jobeet dispose du controleur frontal frontend^cache.php 
qui doit lui aussi etre exclu lors de la phase de deploiement sur le serveur 
de production. 



ASTUCE Prerequis avant ('utilisation 
de la tache project:deploy 

Avant d'executer pour la premiere fois la com- 
mande project:deploy, il est necessaire de 
se connecter au serveur manuellement afin 
d'ajouter la cle dans le fichier des serveurs 
reconnus. 



Information Configuration du serveur SSH 

Bien que le fichier properties . ini accepte la 
definition d'un mot de passe SSH, il est recom- 
mande de configurer le serveur avec une cle SSH 
afin de permettre les connexions sans mot de passe. 
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Exclusion du fichier fontrend_cache.php du processus de deploiement dans le fichier 
config/rsync_exclude.txt 

. svn 

/web/uploads/* 

/cache/* 

/log/* 

/web/*_dev. php 

/web/f rontend cache . php 

Bien que la tache project : deploy de Symfony soit particulierement utile 
et flexible, il arrive parfois quelle doive etre personnalisee davantage 
dans le cas d'un deploiement plus complexe et different selon la configu- 
ration et la typologie du serveur. C'est pour cette raison qu'il ne faut sur- 
tout pas hesiter a ameliorer cette tache en en creant une nouvelle qui 
herite de la classe par defaut. 



ASTUCE Forcer le deploiement de certains fichiers 

II est egalement possible de creer un fichier conf i g/rsync_i ncl ude . txt qui contient 
la liste des fichiers et repertoires qui doivent obligatoirement etre transferes lors du processus 
de deploiement sur le serveur de production final. 



Nettoyer le cache de configuration du serveur de production 

Par ailleurs, a chaque fois qu'un site Internet est definitivement deploye 
sur le serveur de production, il est important de se rappeler de nettoyer 
au moins le cache de la configuration sur le serveur de production. 

j $ php symfony cc --type=config 

Si par exemple la configuration de quelques routes a change, le cache 
specifique du routage doit lui aussi etre regenere. 

$ php symfony cc --type=routi ng 



ASTUCE Avantage du nettoyage selectif du cache 

Nettoyer le cache selectivement permet de conserver certaines parties du cache comme celle 
des templates par exemple. 



En resume 



Le deploiement d'un projet est la toute derniere etape du cycle de vie 
d'un developpement Symfony, mais cela ne signifie pas necessairement 
que c'est la fin. C'est en fait generalement le contraire. . . Par consequent, 
il arrivera tres certainement qu'il y ait des nouveaux bogues a corriger 
ainsi que de nouvelles fonctionnalites a implementer au meme moment. 
Toutefois, grace a la structure de Symfony et a ses nombreux outils mis a 
la disposition des developpeurs, la mise a jour d'un site Internet 
deviendra simple, rapide et sans risque. 

Cette conclusion acheve la realisation de 1' etude de cas Jobeet et met un 
terme a cet ouvrage. Apres une serie de vingt et un chapitres consecutifs 
revelant pas a pas toutes les fonctionnalites essentielles de Symfony, vous 
devriez etre en mesure de piloter et de developper vos propres projets 
personnels et professionnels avec le framework. Cet ouvrage constituera 
par la meme occasion une ressource documentaire de reference supple- 
mentaire a toutes celles qui existent aujourd'hui sur le site officiel du 
projet a l'adresse http://www.symfony-project.org. 



Le format YAML 



A 



La plupart des fichiers dans Symfony sont ecrits en format YAML. 
D'apres le site officiel de YAML, il s'agit d'un « format standard 
de serialisation de donnees, lisible pour tout etre humain, pour tous 
les langages de programmation. . . ». La syntaxe de YAML 
est particulierement riche et ces quelques pages devoilent la plupart 
des concepts du format YAML et ce qu'ils permettent de decrire 
avec les outils de Symfony 



MOTS-CLES : 

► Types de donnees 

► Tableaux et collections 

► Configuration dans Symfony 



Bien que le format YAML puisse decrire des structures de donnees 
imbriquees complexes, cette annexe decrit seulement le jeu de fonction- 
nalites necessaires pour utiliser YAML en guise de simple format de 
fichier de configuration pour Symfony. 

YAML est un langage simple dedie a la description de donnees. Comme 
PHP, il dispose d'une syntaxe pour les types de donnees primitifs tels 
que les chaines de caracteres, les booleens, les nombres decimaux ou 
encore les nombres entiers. Neanmoins, contrairement a PHP, il est 
capable de faire la difference entre les tableaux (sequences) et les tables 
de hachage (mapping). 



Les donnees scalaires 

Les sections suivantes decrivent la syntaxe des donnees scalaires qui sont 
finalement tres proches de la syntaxe de PHP. Ces donnees incluent 
entre autres les entiers, les nombres decimaux, les booleens ou les 
chaines de caracteres. 

Les chaines de caracteres 

Tous les bouts de code presentes dans cette section decrivent la maniere 
de declarer des chaines de caracteres en format YAML. 

A string in YAML 

'A si ngl ed-quoted string in YAML' 

Une chaine de caracteres simple peut contenir des apostrophes. Le 
format YAML impose de doubler les apostrophes intermediates pour 
les echapper. 

| 'A single quote ' ' in a single-quoted string' 

La syntaxe avec des guillemets est notamment utile lorsque la chaine de 
caracteres demarre ou se termine par des caracteres d'espacement spe- 
ciaux tels que les sauts de ligne. 

"A double-quoted string in YAML\n" 

Le style avec les guillemets fournit un moyen d'exprimer des chaines 
arbitraires en utilisant les sequences d'echappement \. C'est notamment 
pratique lorsqu'il est besoin d'embarquer un \n ou un caracteres Unicode 
dans une chaine. 



Lorsqu'une chaine de caracteres contient des retours a la ligne, il est pos- 
sible d'utiliser le style litteral, marque par un caractere pipe \ , qui indique 
que la chaine contiendra plusieurs lignes. En mode litteral, les nouvelles 
lignes sont preservees. 

I V /I |V| I 
//II II- 

Alternativement, les chaines de caracteres peuvent etre ecrites avec la 
syntaxe repliee, marquee par un caractere >, ou chaque retour a la ligne 
est remplace par une espace. 

> 

This is a very long sentence 
that spans several lines in the YAML 
but which will be rendered as a string 
without carriage returns. 

II est bon de remarquer les deux espaces avant chaque ligne dans les 
exemples precedents. lis n'apparaitront pas dans les chaines de caracteres 
PHP finales. 

Les nombres 

Cette section decrit les differentes manieres de declarer des valeurs 
numeraires en format YAML tels que les entiers, les nombres a virgules 
flottantes, les nombres octaux ou bien i'infini. 

Les entiers 

Un entier se declare simplement en indiquant sa valeur. 

# Un entier 
12 

Les nombres octaux 

Un nombre octal se declare de la meme maniere qu'un nombre entier en 
le prefixant par un zero. 

# Un nombre octal 
014 



Les nombres hexadecimaux 

Un nombre hexadecimal se declare en prefixant sa valeur par Ox. 

# Un nombre hexadecimal 
OxC 

Les nombres decimaux 

Un nombre decimal se declare de la meme maniere qu'un entier en indi- 
quant sa partie decimale avec un point. 

# Un nombre decimal 
13.4 

Les nombres exponentiels 

Un nombre exponentiel peut aussi etre represente en format YAML de 
la maniere suivante. 

# Un nombre exponentiel 
1.2e+34 

Les nombres infinis 

L'infini se represente a l'aide de la valeur .inf. 

# L'infini 
.inf 

Les valeurs nulles : les NULL 

Une valeur nulle se materialise en YAML avec la valeur null ou le carac- 
tere tilde ~. 

Les valeurs booleennes 

Les valeurs booleennes sont decrites a l'aide des chaines de caracteres 
true et fal se. II faut egalement savoir que l'analyseur syntaxique YAML 
du framework Symfony reconnait une valeur booleenne si elle est 
exprimee avec l'une de ces valeurs : on, off, yes et no. Neanmoins, il est 
fortement deconseille de les utiliser depuis qu'elles ont ete supprimees 
des specifications de Symfony 1.2. 



Les dates 



Le format YAML utilise le standard ISO 8 601 pour exprimer les dates. 

# Une date complete 

2001- 12-14t21:59:43. 10-05:00 

# Une date simple 

2002- 12-14 



Les collections 

Un fichier YAML est rarement utilise pour decrire uniquement des sim- 
ples valeurs scalaires. La plupart du temps, c'est pour decrire une collec- 
tion de valeurs. Une collection peut etre exprimee a l'aide d'une liste de 
valeurs ou avec une association d'elements. Les sequences et les associa- 
tions sont toutes deux converties sous forme de tableaux PHP. 

Les sequences d'elements 

Les sequences d'elements s'expriment a l'aide d'un tiret - suivi d'un 
espace pour chacun de leurs elements. Le code ci-dessous presente une 
sequence simple de valeurs. 

- PHP 

- Perl 

- Python 

Apres analyse, ce code YAML est converti sous la forme d'un tableau 
PHP simple identique a celui ci-dessous. 

arrayC'PHP' , 'Perl', 'Python'); 

Les associations d'elements 
Les associations simples 

Les associations se representent a l'aide d'un caractere : suivi d'une 
espace pour exprimer chaque couple « cle = > valeur ». 

PHP: 5.2 
MySQL: 5.1 
Apache: 2.2.20 



Apres analyse, ce code YAML est converti sous la forme d'un tableau 
PHP associatif identique a celui ci-dessous. 

arrayC'PHP' => 5.2, 'MySQL' => 5.1, 'Apache' => '2.2.20'); 

II est bon de savoir que chaque cle d'une association peut etre exprimee a 
l'aide de n'importe quelle valeur scalaire valide. D'autre part, le nombre 
d'espaces apres les deux points est completement arbitraire. Par conse- 
quent, le code ci-dessous est strictement equivalent au precedent. 

PHP: 5.2 
MySQL: 5.1 
Apache: 2.2.20 



Les associations complexes imbriquees 

Le format YAML utilise des indentations avec un ou plusieurs espaces 
pour exprimer des collections de valeurs imbriquees comme le montre le 
code ci-apres. 

"symfony 1.0": 

PHP: 5.0 

Propel : 1.2 
"symfony 1.2": 

PHP: 5.2 

Propel: 1.3 

Apres analyse, ce code YAML est converti sous la forme d'un tableau 
PHP associatif a deux niveaux identique a celui ci-dessous. 

array( 

'symfony 1.0' => array( 
'PHP' => 5.0, 
'Propel ' => 1.2, 

), 

'symfony 1.2' => array( 
'PHP' => 5.2, 
'Propel ' => 1.3, 

), 

); 

II y a tout de meme une chose importante a retenir lorsque Ton utilise les 
indentations dans un fichier YAML : les indentations sont toujours rea- 
lisees a l'aide d'un ou plusieurs espaces mais jamais avec des tabulations. 



Combinaison de sequences et dissociations 

Les sequences et les associations peuvent egalement etre combinees de la 
maniere suivante : 

'Chapter 1' : 

- Introduction 

- Event Types 
'Chapter 2 ' : 

- Introduction 

- Helpers 

Syntaxe alternative pour les sequences et associations 

Les sequences et les associations possedent toutes deux une syntaxe 
alternative sur une ligne a l'aide de delimiteurs particuliers. Ces syntaxes 
permettent ainsi de se passer des indentations pour marquer les diffe- 
rents scopes. 

Cas des sequences 

Une sequence de valeurs peut aussi s'exprimer a l'aide d'une liste 
entouree par des crochets [] d'elements separes par des virgules. 

| [PHP, Perl , Python] 

Cas des associations 

Une association de valeurs peut aussi s'exprimer a l'aide d'une liste 
entouree d'accolades { } de couples cle/valeur separes par des virgules. 

| { PHP: 5.2, MySQL: 5.1, Apache: 2.2.20 } 

Cas des combinaisons de sequences et d'associations 

De meme que precedemment, la combinaison des sequences et des asso- 
ciations reste possible avec leur syntaxe alternative respective. Par conse- 
quent, il ne faut pas hesiter a les utiliser pour arriver a une meilleure 
lisibilite du code. 

'Chapter 1': [Introduction, Event Types] 
'Chapter 2': [Introduction, Helpers] 

"symfony 1.0": { PHP: 5.0, Propel: 1.2 } 
"symfony 1.2": { PHP: 5.2, Propel: 1.3 } 



Les commentaires 



Le format YAML accepte l'integration de commentaires pour docu- 
menter le code en les prefixant par le caractere diese #. 

# Commentai re sur une ligne 

"symfony 1.0": { PHP: 5.0, Propel: 1.2 } # Commentai re a la fin 
d'une ligne 

"symfony 1.2": { PHP: 5.2, Propel: 1.3 } 

Les commentaires sont simplement ignores par l'analyseur syntaxique 
YAML et n'ont pas besoin d'etre indentes selon le niveau d'imbrications 
courant dans une collection. 



Les fichiers YAML dynamiques 

Dans Symfony, un fichier YAML peut contenir du code PHP qui sera 
ensuite evalue juste avant que l'analyse du code YAML finale ne se produise. 

1.0: 

version: <?php echo f i 1 e_get_contents( ' 1. 0/VERSION ' ) . "\n" ?> 
1.1: 

version: "<?php echo file_get_contents('l.l/VERSION') ?>" 

II faut bien garder a l'esprit ces quelques petites astuces lorsque du code 
PHP est ajoute au fichier YAML afin ne pas risquer de desordonner 
l'indentation. 

• Linstruction <?php ?> doit toujours demarrer une ligne ou etre 
embarquee dans une valeur. 

• Si une instruction <?php ?> termine une ligne, alors il est necessaire 
de generer explicitement une nouvelle ligne en sortie a l'aide du mar- 
queur \n. 



Exemple complet recapitulatif 



L'exemple ci-dessous illustre la plupart des notations YAML expliquees 
tout au long de cette annexe sur le format YAML. 

"symfony 1.0": 

end_of_mai ntai nance : 2010-01-01 
is_stable: true 
release_manager: "Gregoire Hubert" 

description: > 

This stable version is the right choice for projects 

that need to be maintained for a long period of time. 
1atest_beta: 

latestjninor: 1.0.20 

supported_orms : [Propel] 

archives: { source: [zip, tgz] , sandbox: [zip, 

tgz] } 



"symfony 1.2": 

end_of_mai ntai nance : 2008-11-01 
is_stable: true 
release_manager: 'Fabian Lange' 

description: > 

This stable version is the right choice 
if you start a new project today. 
latest_beta: null 
latest_minor: 1.2.5 
supported_orms : 

- Propel 

- Doctrine 
archives: 

source: 

- zip 

- tgz 
sandbox: 

- zip 

- tgz 



fichierde configuration D 
settinas.vm 1 ^ 




La plupart des aspects de Symfony peuvent etre configures 
a travers un fichier de configuration ecrit en YAML ou avec 
du code PHP pur. 

Cette annexe est consacree a la description 
de tous les parametres de configuration d'une application 
qui se trouvent dans le fichier de configuration principal 
settings. yml du repertoire apps/APPLICATION/config/. 



MOTS-CLES : 

► Configuration de Symfony 

► Format YAML 

► Fichier settings.yml 



Comme il Fa ete mentionne dans l'introduction, le fichier de configura- 
tion settings. yml d'une application est parametrable par environne- 
ment, et beneficie du principe de configuration en cascade. Chaque 
environnement dispose de deux sous-sections: .actions et .settings. 
Toutes les directives de configuration se situent principalement dans la 
sous-section . setti ngs a l'exception des actions par defaut qui sont ren- 
dues pour certaines pages communes. 

Les parametres de configuration du fichier 
settings.yml 

Configuration de la section .actions 

La sous-section .actions du fichier de configuration settings.yml con- 
tient quatre directives de configuration listees ci-dessous. Chacune 
d'entre elles sera decrite independamment dans la suite de cette annexe. 

• error_404 

• login 

• secure 

• module_disabled 

Configuration de la section .settings 

La sous-section .settings du fichier de configuration settings.yml 
contient vingt-deux directives de configuration listees ci-dessous. Cha- 
cune d'entre elles sera decrite independamment dans la suite de cette 
annexe. 

• cache 

• charset 

• check_lock 

• check_symfony_version 

• compressed 

• csrf_secret 

• defaul t_cul ture 

• defaul t_timezone 

• enabled_modules 

• error_reporti ng 

• escaping_strategy 



escapi ng_method 

etag 

il8n 

logging_enabled 
no_script_name 
max_forwards 
standard_hel pers 
stri p_comments 
use_database 
web_debug 
web_debug_web_di r 



La sous-section .actions 



Configuration par defaut 

Le code ci-dessous donne le detail de la configuration par defaut definie 
par Symfony pour les directives de cette sous-section. 

default: 
.actions: 
error_404_module: default 
error_404_action: error404 

login_module: default 
logi n_action : login 

secure_module: default 
secure_action: secure 

modul e_di sabl ed_modul e : default 
modul e_di sabl ed_acti on : di sabl ed 

La sous-section . actions definit les actions a executer lorsque des pages 
communes doivent etre rendues. Chaque definition se decompose en 
deux directives de configuration. La premiere indique le module con- 
cerne (elle est suffixee par _module), tandis que la seconde indique 
Faction a executer dans ce module (elle est suffixee par _action). Les 
parties qui suivent decrivent l'une apres l'autre ces directives de configu- 
ration de Implication. 
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error 404 



L'action error_404 est executee a chaque fois qu'une page d'erreur404 
doit etre rendue. 

login 

L'action login est executee lorsque l'utilisateur tente d'acceder a une 
page alors qu'il n'est pas authentifie. Generalement, la page affichee par 
cette directive est celle qui contient un formulaire d'identification. 

secure 

L'action secure est executee lorsque l'utilisateur tente d'acceder a une 
page pour laquelle il n'a pas les droits d'acces necessaires. 

module disabled 

L'action module_disabled est executee lorsque l'utilisateur demande une 
page d'un module desactive pour l'application. 

La sous-section .settings 

La sous-section . setti ngs est l'endroit ou toute la configuration du fra- 
mework est definie. Les parties qui suivent decrivent tous les parametres 
possibles qui sont, a cette occasion, grossierement tries par ordre 
d'importance. Toutes les valeurs des parametres de cette sous-section 
son disponibles depuis n'importe quel endroit du code par le biais de 
l'objet sfConf i g, et sont prefrxees par sf_. Par exemple, pour connaitre la 
valeur de la directive charset, il suffit de l'appeler de cette maniere : 

| sfConfig: : get( ' sf_charset ' ) ; 

escaping_strategy 

La valeur par defaut de la directive escapi ng_strategy est off. 

La directive de configuration escapi ng_strategy est un booleen qui 
determine si le sous-framework d'echappement des valeurs de sortie doit 
etre active ou non. Quand il est active, toutes les variables rendues dispo- 
nibles dans les templates sont automatiquement echappees par l'appel au 
helper defini par le parametre escapi ngjnethod decrit plus bas. 



La directive escaping_method definit le helper par defaut utilise par 
Symfony, mais celui-ci peut bien sur etre redefini au cas par cas lorsqu'il 
s'agit de rendre une variable dans une balise JavaScript par exemple. Le 
sous-framework d'echappement utilise la valeur du parametre charset 
pour l'echappement. 

II est fortement recommande de changer la valeur par defaut a la valeur on. 

escaping method 

La valeur par defaut de la directive escaping_method est 
ESC_SPECIALCHARS. 

La directive de configuration escapi ng_method definit la fonction par 
defaut a utiliser pour automatiser l'echappement des variables dans les 
templates (voir la directive escapi ng_strategy plus haut). Ce parametre 
accepte l'une des valeurs suivantes : ESC_SPECIALCHARS, ESC_RAW, 
ESC_ENTITIES, ESC_JS, ESC_JS_NO_ENTITIES et ESC_SPECIALCHARS ; sinon 
il faut creer une fonction specifique pour l'echappement. 

La plupart du temps, la valeur par defaut suffit. Le helper ESC_ENTITIES 
peut aussi etre utilise, particulierement lorsqu'il s'agit de travailler avec 
des langues anglaises ou europeennes. 



ASTUCE Activer automatiquement la 
strategie d'echappement 

La valeur de la strategie d'echappement des don- 
nees peut etre definie automatiquement au 
moment de la creation de I'application en ajoutant 
I'option --escapi ng_strategy a la com- 
mande generate :app. 



csrf secret 



La valeur par defaut de la directive csrf_secret est fal se. 

La directive de configuration csrf_secret permet de definir un jeton 
unique pour I'application. Lorsqu'elle n'est pas a la valeur false, elle 
active la protection contre les vulnerabilites CSRF dans tous les formu- 
laires generes a partir du framework de formulaire de Symfony. Ce para- 
metre est egalement embarque dans le helper link_to() lorsqu'il a 
besoin de convertir un lien en formulaire afin de simuler la methode 
HTTP PUT par exemple. 

II est fortement recommande de changer la valeur par defaut par un 
jeton unique. 



ASTUCE Activer automatiquement 
la protection CSRF 

La valeur du jeton contre les vulnerabilites CSRF 
peut etre definie automatiquement au moment de 
la creation de I'application en ajoutant a la com- 
mande --csrf_secret I'option : 
generate:app. 



charset 

La valeur par defaut de la directive charset est utf-8. 

La directive de configuration charset definit la valeur de l'encodage qui 
sera utilise par defaut dans tout le framework de la reponse (en-tete 
Content-Type) jusqu'aux informations echappees dans les templates. La 
plupart du temps, la configuration de ce parametre suffit. 
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enabled-modules 



Remarque 

Definir un f useau horaire par defaut 

Si aucun fuseau horaire n'a ete defini pour cette 
directive de configuration, il est fortement recom- 
mande de le declarer dans le fichier de configura- 
tion php.ini du serveur etant donne que 
Symfony essaiera de determiner le fuseau horaire 
approprie d'apres la valeur retournee par la fonction 
PHP date_default_timezone_get(). 



ASTUCE 

Parametrage du cache des pages HTML 

La configuration du systeme de cache des pages 
HTML doit etre realisee au niveau des sections 
view_cache et vi ew_cache_manager du 
fichier de configuration facto ries.yml (voir 
annexe 3). La configuration par niveau de granula- 
rity la plus fine est geree quant a elle par le biais 
du fichier de configuration cache . yml . 



La valeur par defaut de la directive enabled_modules est [default]. 

La directive de configuration enabled_modules est un tableau des noms 
des modules a activer pour l'application courante. Les modules definis 
dans les plug-ins ou dans le cceur de Symfony ne sont pas actives par 
defaut, et doivent absolument etre listes dans ce parametre pour etre 
accessibles. 

Ajouter un nouveau module est aussi simple que de l'enregistrer dans la 
liste. Lordre des modules actives n'a aucune incidence. 

enabled_modules: [default, sfGuardAuth] 

Le module default defini par defaut dans le framework contient toutes 
les actions par defaut qui sont declarees dans la sous-section . actions du 
fichier de configuration settings. yml. II est vivement recommande de 
personnaliser chacune de ces actions, puis de supprimer le module 
default de la liste de ce parametre. 

default timezone 

La valeur par defaut de la directive def aul t_ti mezone est none. 

La directive de configuration default_ti mezone definit le fuseau horaire 
utilise par PHP. La valeur peut etre himporte quel fuseau horaire 
reconnu par PHP (voir http://www.php.net/manual/en/class.datetimezone.php). 

cache 

La valeur par defaut de la directive cache est off. 

La directive de configuration cache active ou non le cache des pages 
HTML. 

ctag 

La valeur par defaut de la directive etag est on, a 1' exception des environ- 
nements dev et test pour lesquels elle est desactivee. 

La directive de configuration etag active ou desactive la generation auto- 
matique des en-tetes HTTP ETag. Les ETag generes par Symfony sont 
de simples calculs MD5 du contenu de la reponse. 
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il8n 



La valeur par defaut de la directive i 18n est off. 

La directive de configuration il8n est un booleen qui active ou non le 
sous-framework d'internationalisation de Symfony. Pour les applications 
internationalisees, la valeur de ce parametre doit etre placee a on. 

default culture 

La valeur par defaut de la directive defau"lt_cul ture est en. 

La directive de configuration default_culture definit la culture par 
defaut que le sous-framework d'internationalisation utilisera. Ce para- 
metre accepte n'importe quelle valeur valide de culture. 

standard helpers 

La valeur par defaut de la directive standard_helpers est [Partial, 
Cache, Form]. 

La directive de configuration standard_he1pers definit tous les groupes 
de helpers a charger automatiquement pour tous les templates de 1' appli- 
cation. Les valeurs indiquees sont les noms de chaque groupe de helpers 
sans leur suffixe Hel per. 

no_script_name 

La valeur par defaut de la directive no_scri pt_name est on pour l'environ- 
nement de production de la toute premiere application creee dans le 
projet, et off pour tous les autres. 

La directive de configuration no_script_name determine si le nom du 
controleur frontal doit apparaitre ou non dans FURL avant les URLs 
generees par Symfony. Par defaut, il est fixe a la valeur on par la tache 
automatique gene rate :app pour l'environnement prod de la toute pre- 
miere application creee. 

De toute evidence, seulement une application et un environnement peu- 
vent avoir ce parametre a la valeur on si tous les controleurs frontaux se 
trouvent dans le meme repertoire (web/ par defaut). Pour avoir plusieurs 
applications avec la directive de configuration no_scri pt_name a la valeur 
on, il suffit de deplacer le ou les controleurs frontaux sous un sous-reper- 
toire du repertoire web/ racine. 



ASTUCE Parametrage du systeme d'H8N 

La configuration generale du systeme d'internatio- 
nalisation doit etre realisee au niveau de la section 
il8n du fichier factories.yml (voir 
annexe C). 
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ASTUCE Parametrage du systeme 
d'enregistrement des traces de logs 

La configuration generale du systeme d'enregistre- 
ment des logs doitetre realisee dans le fichier de con- 
figuration factories .yml (voir annexe 3) afin 
de determiner son niveau de granularite le plus fin. 



logging enabled 

La valeur par defaut de la directive 1 oggf ng_enabl ed est on pour tous les 
environnements a l'exception de renvironnement de production prod. 

La directive de configuration logging_enabled active le sous-framework 
d'enregistrement des traces de logs. Fixer la valeur de ce parametre a 
false permet de detourner completement le mecanisme d'enregistre- 
ment des logs et ainsi d'ameliorer legerement les performances. 

web debug 

La valeur par defaut de la directive web_debug est on pour tous les envi- 
ronnements a l'exception de l'environnement de developpement dev. 

La directive de configuration web_debug active la generation de la barre 
de debogage de Symfony. La barre de debogage est ajoutee a toutes les 
pages web ayant la valeur HTML dans l'en-tete de type de contenu. 



Remarque 

En savoir plus sur les niveaux d'erreurs 

Le site officiel de PHP donne des informations 
complementaires sur comment utiliser les opera- 
teurs bit-a-bit a I'adresse http://www.php.net/ 
language.operators.bitwise. 



Remarque Deactivation des erreurs 
dans le navigateur 

L'affichage des erreurs dans le navigateur est auto- 
matiquement desactive pour les applications qui 
ont la directive de configuration debug desac- 
tivee, ce qui est le cas par defaut pour l'environne- 
ment de production. 



error_reporting 

Les valeurs par defaut de la directive error_reporti ng sont les suivantes 
en fonction de l'environnement d'execution du script : 

• prod : E_PARSE | E_COMPILE_ERROR | E_ERROR | E_CORE_ERROR | 
E_USER_ERROR 

• dev : E_ALL | E_STRICT 

• test : (E_ALL | E_STRICT) A E_N0TTCE 

• default : E_PARSE | E_C0MPILE_ERR0R | E_ERR0R | E_C0RE_ERR0R | 
E_USER_ERROR 

La directive de configuration error_reporting controle le niveau 
d'erreurs a rapporter dans le navigateur et a ecrire dans les fichiers de 
logs. La configuration actuelle est la plus sensible, c'est pourquoi elle ne 
devrait pas avoir a etre modifiee. 

compressed 

La valeur par defaut de la directive compressed est off. 

La directive de configuration compressed active ou non la compression 
automatique du contenu de la reponse. Si la valeur de ce parametre est a 
on, alors Symfony utilisera la fonction native ob_gzhandler() de PHP en 
guise de fonction de rappel a la fonction ob_start(). 

II est neanmoins recommande de la garder a la valeur off, et d'utiliser a 
la place le mecanisme de compression natif supporte par le navigateur. 
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use database 

La valeur par defaut de la directive use_database est on. 

La directive de configuration use_database indique si oui ou non 1' appli- 
cation necessite l'usage d'une base de donnees. 

check lock 

La valeur par defaut de la directive check_l ock est off. 

La directive de configuration check_lock active ou non le systeme de 
verrouillage de l'application declenche par certaines taches automatiques 
telles que cache: clear. 

Si la valeur de ce parametre de configuration est a on, alors toutes les 
requetes en direction des applications desactivees seront automatique- 
ment redirigees vers la page 1 i b/excepti on/data/unavai 1 abl e . php. 

check_symfony_version 

La valeur par defaut de la directive check_symfony_version est off. 

La directive de configuration check_symfony_version active ou non le 
controle de la version de Symfony a chaque requete executee. Si ce para- 
metre est active, Symfony vide le cache automatiquement lorsque le fra- 
mework est mis a jour. 

II est vivement recommande de ne pas fixer la valeur de cette directive a 
on etant donne quelle ajoute un leger cout supplemental sur les perfor- 
mances et qu'il est simple de nettoyer le cache lorsqu'une nouvelle ver- 
sion du projet est deployee. Ce parametre est seulement utile si plusieurs 
projets partagent le meme code source de Symfony, ce qui n'est verita- 
blement pas recommande. 

web_debug_dir 

La valeur par defaut de la directive web_debug_di r est /sf/sf_web_debug. 

La directive de configuration web_debug_di r definit le repertoire qui 
contient toutes les ressources web necessaires au bon fonctionnement de 
la barre de debogage de Symfony telles que les feuilles de style CSS, les 
fichiers JavaScript ou encore les images. 
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strip_comments 



La valeur par defaut de la directive strip_comments est on. 

La directive de configuration strip_comments determine si Symfony 
devrait supprimer les commentaires lorsqu'il compile les classes du 
noyau. Ce parametre est uniquement utilise si le parametre de configu- 
ration debug de l'application est fixe a la valeur off. 

Si des pages blanches apparaissent uniquement en environnement de 
production, alors il convient de reessayer en definissant ce parametre de 
configuration a la valeur off. 

max forwards 

La valeur par defaut de la directive max_forward est 5. 

La directive de configuration max_forward determine le nombre 
maximum de redirections internes (forward () dans les actions) autori- 
sees avant que Symfony ne leve une exception. Ce parametre de configu- 
ration est une securite pour se premunir des boucles sans fin. 



fichierde configuration 
factories.vml 



C 



Tous les objets internes de Symfony necessaires au bon 
traitement des requetes comme request, response ou user, 
sont generes automatiquement par l'objet sfContext. 
Or, il arrive parfois que les classes utilisees pour construire 
ces objets ne suffisent pas pour subvenir aux besoins 
de l'application ; elles doivent alors etre remplacees 
par des classes personnalisees. 

Grace au fichier de configuration factories.yml 

de l'application, Symfony autorise le developpeur a definir 

lui-meme son contexte d'execution. 



MOTS-CLES : 

► Configuration de Symfony 

► Format YAML 

► Fichier factories.yml 



Introduction a la notion de « factories » 



Classe de conversion 
du fichier factories.yml en code PHP 

La conversion du fichier de configuration 
factories.yml en PHP est realisee par la 
classe PHP sf FactoryConf i gHandl er. 



Les factories sont les objets du noyau de Symfony et qui sont necessaires 
au framework durant tout le cycle de vie du traitement de la requete. Ces 
objets sont tous definis dans le fichier de configuration factories.yml 
du repertoire apps/APPLICATION/config/ et sont toujours accessibles 
depuis n'importe oil par i'intermediaire de l'objet sfContext. 

| sfContext: : getlnstanceO ->getUser() ; 

Le fichier de configuration factories .yml d'une application est parame- 
trable par environnement, et beneficie du principe de configuration en 
cascade. II peut egalement prendre en compte les constantes globales 
definies par Symfony. 

Lorsque l'objet sfContext initialise les factories, il lit le fichier 
factories.yml pour en decouvrir les noms des classes (class) qu'il doit 
instancier et la liste des parametres (param) qu'il doit transmettre au 
constructeur respectif de ces dernieres. La description generale en 
format YAML d'un objet factory est la suivante : 

FACTORY_NAME : 

class: CLASS_NAME 

param: { ARRAY OF PARAMETERS } 

Etre capable de personnaliser les factories signifie aussi utiliser des 
classes personnalisees pour les objets du cceur de Symfony a la place de 
ceux qui sont crees par defaut. Par consequent, cette liberte de configu- 
ration offre au developpeur la possibilite de changer les comportements 
par defaut de ces objets en leur passant d'autres parametres. 



Presentation du fichier factories.yml 



Configuration du service request 

Linitialisation de l'objet requete par le contexte d'execution est assuree 
par quatre parametres de configuration du fichier factories.yml. 
Chaque parametre de configuration liste ci-dessous sera decrit indepen- 
damment dans la suite de cette annexe. 

• path_i nfo_array 

• path_i nfo_key 

• formats 

• relati ve_url_root 
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Configuration du service response 3 

c 

_o 

L'initialisation de l'objet reponse par le contexte d'execution est assuree S 
par trois parametres de configuration du fichier factories.yml. Chaque -S 
parametre de configuration liste ci-dessous sera decrit independamment ^ 
dans la suite de cette annexe. "| 

• send„http_headers ;= 

• charset 1* 

• http_protocol u 

Configuration du service user 

L'initialisation de l'objet utilisateur par le contexte d'execution est 
assuree par trois parametres de configuration du fichier factories.yml. 
Chaque parametre de configuration liste ci-dessous sera decrit indepen- 
damment dans la suite de cette annexe. 

• timeout 

• use_flash 

• default_culture 

Configuration du service storage 

L'initialisation de l'objet de session par le contexte d'execution est assuree 
par treize parametres de configuration du fichier f actori es . yml . Chaque 
parametre de configuration liste ci-dessous sera decrit independamment 
dans la suite de cette annexe. 



auto_start 






session_name 






session_cache 




li miter 


session_cooki 


e 


_lifetime 


session_cooki 


e 


_path 


session_cooki 


e 


_domai n 


session_cooki 


e 


_secure 


session_cooki 


e 


_httponly 


database 






db_table 






db_i d_col 






db_data_col 






db_time_col 
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Configuration du service il8n 

L'initialisation de l'objet cY internationalisation par le contexte d'execu- 
tion est assuree par cinq parametres de configuration du fichier 
facto n'es.yml. Chaque parametre de configuration liste ci-dessous sera 
decrit independamment dans la suite de cette annexe. 

• source 

• debug 

• untranslatecLprefix 

• untranslated_suffix 

• cache 

Configuration du service routing 

^initialisation de l'objet de routage par le contexte d'execution est 
assuree par sept parametres de configuration du fichier facto ries.yml. 
Chaque parametre de configuration liste ci-dessous sera decrit indepen- 
damment dans la suite de cette annexe. 

• variable_prefixes 

• segment_separators 

• generate_shortest_url 

• extra_parameters_as_query_stri ng 

• cache 

• suffix 

• load_configuration 

Configuration du service logger 

reinitialisation de l'objet cY enregistrement des traces de log par le contexte 
d'execution est assuree par deux parametres de configuration du fichier 
facto ries.yml. Chaque parametre de configuration liste ci-dessous sera 
decrit independamment dans la suite de cette annexe. 

• level 



• loggers 



Le service request | 

2 

Configuration par defaut 1 

Le service request est accessible grace a l'accesseur getRequestO de "| 
l'objet sfContext. if 

—I 

| sfContext: :getInstance()->getRequest() ^ 

La configuration par defaut du service request est la suivante : 

request : 

class: sfWebRequest 
param: 

logging: %SF_LOGGING_ENABLED% 
path_info_array: SERVER 
path_info^key: PATH_INFO 
rel ati ve_url_root : ~ 
formats : 

txt: text/plain 

js: [application/javascript, appl i cati on/x- javascri pt , 
text/javascript] 

ess: text/ess 

json: [appl i cati on/ j son, application/x-json] 

xml : [text/xml , appl i cati on/xml , appl i cati on/x-xml] 

rdf: appl i cati on/rdf+xml 

atom: appl i cati on/atom+xml 

path info array 

Loption path_i nfo_array definit le tableau PHP superglobal qui doit 
etre utilise pour retrouver les informations. Sur certaines configurations 
de serveur web, il arrive parfois que Ton veuille changer la valeur par 
defaut SERVER en ENV. 



path_info_kcy 

Loption path_i nfo_key definit la cle dans le tableau PHP superglobal 
avec laquelle il est possible de retrouver 1'information PATH_INF0. Les 
utilisateurs de serveurs web IIS configures avec un moteur de reecriture 
d'URLs comme IIFR ou ISAPI devront certainement changer la valeur 
de cette directive de configuration par HTTP_X_REWRITE_URL. 
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formats 



ASTUCE Utiliser la methode setFormat() 
de I'objet request 

Au lieu de redefinir cette directive de configura- 
tion, il est possible d'avoir recours a la methode 
setFormatO de la classe de I'objet de la 
requete. 



L'option formats definit un tableau associatif d'extensions et leurs valeurs 
respectives d'en-tete de types de contenu. Ce parametre de configuration 
est utilise par le framework pour gerer automatiquement Fen-tete Content- 
Type de la reponse, en partant de l'extension de FURL de la requete. 

rcIativc_root_urI 

L'option rel ati ve_root_u rl definit la valeur de la partie de FURL qui se 
trouve avant le nom du controleur frontal. La plupart du temps, cette 
valeur est deduite automatiquement par le framework, ce qui implique 
qu'il n'est pas necessaire de la modifier. 



Le service response 

Configuration par defaut 

Le service response est accessible grace a I'accesseur getResponseO de 
I'objet sfContext. 

j sfContext: : getlnstance() ->getResponse() 

La configuration par defaut du service response est la suivante : 

response: 

class: sfWebResponse 
param: 

logging: %SF_LOGGING_ENABLED% 
charset: %SF_CHARSET% 
send_http_headers : true 

Le code ci-dessous donne la configuration par defaut du service 
response en environnement de test. 

response : 

class: sfWebResponse 
param: 

send_http_headers : false 

send_http_headers 

L'option sendjittpjieaders definit si la reponse a besoin d'envoyer les 
en-tetes HTTP avec son contenu. Ce parametre de configuration est 
essentiellement utilise en environnement de test etant donne que Fenvoi 
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des en-tetes est realise par la fonction native PHP header () qui pro- 3 
voque des avertissements lorsque des en-tetes sont envoyes apres les pre- .1 
mieres sorties au navigateur. § 

c 

s 

charset il 

.Si 

L'option charset definit l'encodage a utiliser pour la reponse. Par defaut, == 
la valeur de cette directive de configuration est la meme que celle definie i 
a l'entee charset dans le fichier de configuration settings. yml de 
i'application. 



http_protocol 

L'option http_protocol determine la version du protocole HTTP a uti- 
liser pour transmettre la reponse. Par defaut, Symfony ira chercher cette 
valeur dans la variable superglobale $_SERVER[ ' SERVER_PROTOCOL ' ] si elle 
existe, ou utilisera HTTP/1.0 par defaut. 



Le service user 

Configuration par defaut 

Le service user est accessible grace a l'accesseur getUserO de l'objet 
sfContext. 

j sfContext: :getInstance()->getUser() 

La configuration par defaut du service user est la suivante : 

user : 

class: myUser 
param: 

timeout: 1800 

logging: %SF_LOGGING_ENABLED% 

use_flash: true 

def aul t_cul ture : %SF_DEFAUI_T_CULTURE% 

Par defaut, la classe myUser herite des proprietes et des methodes de la 
classe sfBasicSecurityUser, qui peut etre configuree dans le fichier de 
configuration security. yml . 
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timeout 



Pour eviter des effets de bord etranges, la classe 
de gestion de I'utilisateur force automatiquement 
la duree de vie maximale du ramasse-miettes 
[garbage collector) de la session 
(session.gcjnaxlifetime) a une valeur 
strictement superieure a celle du parametre 
timeout. 



Remarque Eviter les effets de bord 
avec I'objet User 



L'option timeout definit le temps maximum pendant lequel I'utilisateur 
dispose de son authentification et de ses droits d'acces. Cette valeur nest 
pas relative a celle definie dans la session. Ce parametre de configuration 
est seulement utilise par les classes de gestion de I'utilisateur qui heritent 
de la classe de base sfBasicSecurityUser, ce qui est le cas pour la classe 
autogeneree myUser de chaque application. 



use flash 



L'option use_flash active ou desactive l'utilisation des messages ephe- 
meres stockes dans la session de I'utilisateur entre deux requetes HTTP. 



L'option default_cu"lture determine la culture par defaut a assigner a 
I'utilisateur lorsque celui-ci arrive pour la premiere fois sur le site 
Internet. Par defaut, cette valeur est recuperee de la directive de configu- 
ration default_culture du fichier de configuration settings. yml, ce qui 
est generalement le comportement de la plupart des applications. 



Le service storage est utilisee par le service user pour assurer la persis- 
tance des donnees de session de I'utilisateur entre chaque requete 
HTTP, et est accessible grace a l'accesseur getStorageO de I'objet 
sfContext. 

| sfContext: : getlnstance() ->getStorage() 

La configuration par defaut du service storage est la suivante : 

storage: 

class: sfSessionStorage 
param: 

session_name : symfony 



default culture 



Le service storage 



Configuration par defaut 
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Une configuration par defaut speciale pour l'environnement de test est 
egalement mise en place. Elle est decrite dans le code ci-dessous. 

storage: 

class: sfSessionTestStorage 
param: 

sessi on_path : %SF_TEST_CACHE_DIR%/sessi ons 

auto start 

L'option auto_start active ou desactive le demarrage automatique de la 
session PHP par le biais de la fonction sessi on_start(). 

session_name 

L'option sessi on^name definit le nom du cookie de session utilise par 
Symfony pour sauvegarder l'identifiant de session de l'utilisateur. Par 
defaut, le nom est Symfony, ce qui signifie que toutes les applications du 
projet partagent le meme cookie, et par consequent les authentifications 
et droits d'acces correspondants. 

Parametres de la fonction session_set_cookie_paramsO 

Le service storage fait appel a la fonction PHP 
sessi on_set_cookie_params() avec les valeurs des options suivantes : 

• sessi on_cookie_lifeti me : duree de vie totale du cookie de session 
definie en secondes ; 

• sessi on_cookie_path : domaine de validite du cookie sur le serveur. 
La valeur / indique que le cookie est valable sur tout le domaine ; 

• sessi on_cooki e_domai n : domaine du cookie, par exemple, 
www.php.net. Pour rendre les cookies visibles par tous les sous- 
domaines, la valeur doit etre prefixee d'un point comme . php . net ; 

• sessi on_cookie_secu re : si la valeur est true, le cookie sera envoye 
sur des connexions securisees ; 

• sessi on_cooki e_httponl y : si la valeur est true, PHP attendra 
d'envoyer le drapeau httponl y lorsqu'il parametrera le cookie de session. 

session_cache_limiter 

Si l'option sessi on_cache_1i miter est definie, la fonction native de 
PHP sessi on_cache_l imiterO sera appelee et la valeur de cette direc- 
tive de configuration sera passee en argument de la fonction. 



Remarque Documentation de la fonction 
session set cookie paramsO 

La description de chaque option de configuration 
de la fonction session_set_cookie_params() 
provient directement de la documentation offi- 
cielle en ligne disponible a I'adresse http:// 
fr.php.net/session-set-cookie-params. 
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Options de stockage des sessions en bases de donnees 

Lorsque Ton utilise un systeme de stockage des sessions qui herite de la 
classe sfDatabaseSessionStorage, certaines options specifiques sont 
disponibles : 

• database : le nom de la base de donnees (obligatoire) ; 

• db_tab1e: le nom de la table qui stocke les donnees de session 
(obligatoire) ; 

• db i d_col : le nom de la colonne qui contient la cle primaire (sess_i d 
par defaut) ; 

• db_data-col : le nom de la colonne qui contient les donnees de ses- 
sion serialisees (sess_data par defaut) ; 

• db_time_col : le nom de la colonne dans laquelle est stockee le date 
de la session (sess_time par defaut). 



Le service view_cache_manager 

Le service view_cache_manager est accessible grace a l'accesseur 
getViewCacheManagerO de l'objet sfContext. 

J sfContext: : getlnstance() ->getVi ewCacheManager() 

La configuration par defaut du service view_cache_manager est la 
suivante : 

! view_cache_manager: 

class: sfViewCacheManager 

Cette factory est uniquement initialisee si le parametre de configuration 
cache est defini a la valeur on. La configuration du gestionnaire de cache 
des pages HTML est realisee via le service vi ew_cache qui definit l'objet 
cache sous-jacent a utiliser pour le cache des vues. 



Le service view_cache 

Le service view_cache est accessible depuis l'accesseur 

getViewCacheManagerO de l'objet sfContext. La configuration par 
defaut du service view_cache est la suivante : 



view_cache: 4S 

class: sfFileCache § 

param: S 

automati c_cl eani ng_f actor: 0 & 

cache_dir: %SF_TEMPLATE_CACHE_DIR% | 

lifetime: 86400 3 

prefix: %SF_APP_DIR%/templ ate M 

"5 

Cette factory est uniquement initialisee si le parametre de configuration % 

cache est defini a la valeur on. Le service view_cache declare une classe ° 
qui doit absolument heriter de sfCache. 



Le service il8n 

Configuration par defaut 

Le service il8n est accessible grace a l'accesseur getI18N() de l'objet 
sfContext. 

j sfContext: :getInstance()->getI18N() 

La configuration par defaut du service i 18 n est la suivante : 

i 18n : 

class: sfI18N 
param: 

source: XLIFF 
debug: off 
untranslated_prefix: " [T] " 
untranslated_suffix: " [/T] " 
cache: 

class: sfFileCache 

param: 

automati c_cl eani ng_factor: 0 

cache_di r : %SF_I18N_CACHE_DIR% 

lifetime: 31556926 

prefix: %SF_APP_DIR%/i 18n 

Cette factory est uniquement initialisee si le parametre de configuration 
i 18n est defini a la valeur on. 



source 

Loption source definit le type de container des traductions au choix 
parmi XLIFF, MySQL, SQLite ou gettext. 
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debug 



L'option debug active ou desactive le debogage. Si cette directive de con- 
figuration est activee, alors les messages non traduits seront decores avec 
un prefixe et un suffixe (voir ci-dessous). 

untranslated prefix 

L'option untranslated_prefix definit un prefixe a utiliser pour decorer 
les messages non traduits. 

untranslated sufix 

L'option untranslated_sufix definit un suffixe a utiliser pour decorer les 
messages non traduits. 

cache 

L'option cache definit une factory de cache anonyme a utiliser pour 
mettre en cache les donnees internationalisees. 



Le service routing 



Configuration par defaut 

Le service routing est accessible grace a I'accesseur getRoutingO de 
l'objet sfContext. 

J sfContext: :getInstance()->getRouting() 

La configuration par defaut du service routi ng est la suivante : 

routing: 

class: sf PatternRouti ng 
param: 

loacLconfiguration: true 
suffix: 

defaul t_modul e : default 

defaul t_acti on: index 

debug: %SF_DEBUG% 

logging: %SF_LOGGING_ENABLED% 

generate_shortest_url : true 

extra_parameters_as_query_stri ng : true 



cache: 4S 

class: sfFileCache § 

param: S 

automatical eaning_factor: 0 & 

cache_dir: %SF_CONFIG_CACHE_DIR%/routi ng | 

lifetime: 31556926 3 

prefix: %SF_APP_DIR%/routi ng M 

"5 

^= 

o> 
_J 

variables prefix u 

La valeur par defaut de I'option vari abl es_pref i x est : . 

Loption vari abl es_prefix definit la liste des caracteres qui demarre le 
nom d'une variable dans un motif d'URL d'une route. 



segment separators 

La valeur par defaut de I'option segment_separators est / et .. 

Loption segment_separators definit la liste des separateurs de segments 
des routes. La plupart du temps, cette option nest pas redefinie pour 
tout le framework de routage mais uniquement pour une seule route par- 
ticuliere. 

generate_shortest_url 

La valeur par defaut de I'option generate_shortest_url est true pour les 
nouveaux projets et false pour les projets mis a jour. 

Si la valeur de I'option generate_shortest_url est fixee a la valeur true, 
le sous-framework de routage generera la route la plus courte possible. 
Cette directive de configuration doit en revanche rester a la valeur f al se 
afin de conserver une compatibilite retrograde avec les versions 1.0 et 1.1 
de Symfony. 

extra_parameters_as_query_string 

La valeur par defaut de I'option extra_parameters_as_query_string est 
true pour les nouveaux projets et f al se pour les projets mis a jour. 

Lorsque des parametres ne sont pas utilises dans la generation de la 
route, la directive de configuration extra_parameters_as_query_string 
autorise ces arguments supplementaires a etre convertis sous la forme 
d'une chaine de requete. Placer la valeur a f al se de ce parametre dans un 
projet Symfony 1.2 permet de revenir au comportement des version 1.0 
et 1.1 de Symfony. En revanche, pour ces dernieres, les parametres sup- 
plementaires seront simplement ignores par le systeme de routage. 



479 



cache 



L'option cache definit une factory de cache anonyme a utiliser pour 
mettre en cache la configuration et les donnees du systeme de routage. 

suffix 

La valeur par defaut de l'option suffix est none. 

L'option suf f i x definit le suffrxe a ajouter au bout de chaque route, mais 
cette fonctionnalite est desormais depreciee depuis l'integration du nou- 
veau framework de routage de Symfony 1.2. Par consequent, cette direc- 
tive de configuration devient inutile bien quelle soit toujours presente. 

load configuration 

La valeur par defaut de l'option "loacLconfiguration est true. 

L'option "loacLconfiguration precise si le fichier de configuration 
routing. yml doit etre automatiquement charge et analyse. La valeur 
f al se doit etre frxee pour utiliser le systeme de routage a l'exterieur d'un 
projet Symfony. 



Le service logger 



Configuration par defaut 

Le service logger est accessible grace a l'accesseur getl_ogger() de l'objet 
sfContext. 

| sfContext: : getlnstanceO ->getl_ogger() 

La configuration par defaut du service logger est la suivante : 

logger: 

class: sfAggregateLogger 
param: 

1 evel : debug 
loggers : 

sf_web_debug : 

class: sfWebDebugLogger 
param: 

level: debug 

condition: %SF_WEB_DEBUG% 
xdebug_logging: true 
web_debug_class: sfWebDebug 



sf_file_debug: 

class: sf Fi 1 eLogger 
param: 

level: debug 

f i 1 e : %SF_LOG_DIR%/%SF_APP%_%SF_ENVIRONMENT%. 1 og 

Le service logger beneficie egalement d'une configuration par defaut 
pour 1'environnement de production prod. 

logger: 

class: sfNoLogger 
param: 

1 evel : err 

loggers: ~ 

Cette factory est toujours initialisee, mais la procedure d'enregistrement 
des traces de logs se produit uniquement si le parametre 
1 oggi ng_enabl ed est defini a la valeur on. 

level 

L'option 1 evel definit le niveau de gravite des informations de logs a 
enregistrer et prend une valeur parmi EMERG, ALERT, CRIT, ERR, WARNING, 
NOTICE, INFO OU DEBUG. 

loggers 

L'option loggers definit une liste des objets a utiliser pour enregistrer les 
traces de logs. Cette liste est un tableau de factories anonymes d'objets 
de log qui figurent parmi les classes suivantes : sfConsoleLogger, 
sfFil eLogger, sfNoLogger, sfStreamLogger et sfVarLogger. 



Le service controller 

Configuration par defaut 

Le service controller est accessible grace a I'accesseur getController() 
de l'objet sfContext. 

| sfContext: :getInstance()->getController() 

La configuration par defaut du service control 1 er est la suivante : 

control 1 er : 

class: sfFrontWebController 



Les services de cache anonymes 

Plusieurs factories (view_cache, il8n et routing) tirent partie des avan- 
tages de l'objet de cache s'il est defini dans leur configuration respective. 
La configuration de l'objet de cache est similaire pour toutes les facto- 
ries. La cle cache definit une factory de cache anonyme. Comme 
n'importe quelle autre factory, elle accepte deux entrees : class et param. 
La section param peut prendre n'importe quelle option disponible pour la 
classe de cache. 

Loption prefix est la plus importante de toutes etant donne quelle 
permet de partager ou de separer un cache entre differents environne- 
ments/applications/projets. 

Les classes natives de cache dans Symfony sont sfAPCCache, 
sfEAcceleratorCache, sf Fi 1 eCache, sfMemcacheCache, sfNoCache, 
sfSQLiteCache et sfXCacheCache. 
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